Community
Participate
Working Groups
We use Jetty 7.4.x to run integration tests for RAP. The tests are simulating requests on an embedded Jetty server instance and then analyze session data to assert that certain conditions are met. To obtain session data, we use AbstractSessionManager#getSessionMap(). Since Jetty 8.x, getSessionMap() throws an UnsupportedOperationException. Can these changes be reverted? Or is there another way to obtain all sessions?
Personally I would prefer to not put the method back as with certain session scenarios it really isn't 'all session' instead just the ones that a particular instance knows about. If you what you looking for though I would register a HttpSessionListener and watch for the create and destroy actions, probably a better granular for you and you don't rely on internal methods. If this doesn't work for you just reopen and explain a bit more why it won't work and I'll see what we can do cheers
(In reply to comment #1) > If you what you looking for though I would register a HttpSessionListener and > watch for the create and destroy actions, probably a better granular for you and > you don't rely on internal methods. While adding an HttpSessionListener to get a list of all sessions works well if testing with a single embedded Jetty server, it fails with clustered Jetty engines. It seems that the sessionCreated() event isn't fired if a session is deserialized. We are creating programmatically two Jetty servers and have them form a cluster by configuring JDBCSessionManagers and JDBCSessionIdManagers that use a common database to communicate. After starting both instances, we issue requests on the first node, thenwithin the same session (simulating a failover) on the second node. The (old) getSessionMap() method returned all sessions for both nodes, regardless whether they were actually created or just deserialized. that was just what we wanted to see. With the HttpSessionListener approach, we see all sessions that were created on the primary node. On the failover node, however, no sessions are listed. How can we track all sessions (originally created as well as deserialized from another node) on a particular node? The code we use to set up single and clustered Jetty engines can be viewed here: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.rap/runtime.rwt.test/org.eclipse.rap.rwt.cluster.testfixture/src/org/eclipse/rap/rwt/cluster/testfixture/internal/jetty/?root=RT_Project
ah ha...ok let me dig a bit on this and get back to you, we have tests similar to this use case I'll sort out, it could be that we don't expose enough information to do what your specifically looking for here. will get back to you
Nightly here I think, let me know if you have issues http://download.eclipse.org/jetty/updates/jetty-bundles-7.x/development
(In reply to comment #4) > Nightly here I think, let me know if you have issues > > http://download.eclipse.org/jetty/updates/jetty-bundles-7.x/development I am afraid, there seems to be an unsatisifed dependency to org.eclipse.jetty.annotations or something. I opened bug 358357.
(In reply to comment #4) > Nightly here I think, let me know if you have issues > > http://download.eclipse.org/jetty/updates/jetty-bundles-7.x/development Please disregard comment #5. Is there a development repo for 8.x as well? I tried .../jetty-bundles-8.x/development but it delivers only bundles with version 8.0.0.RC0-SNAPSHOT even though there already is a stable 8.0.1
(In reply to comment #4) > Nightly here I think, let me know if you have issues > > http://download.eclipse.org/jetty/updates/jetty-bundles-7.x/development The 7.x developemnt repository contains only bundles with version 7.5.0.v20110901. The changes for bug 358263 are not contained.
If you are just doing this for testing purposes, how about connecting straight to the database and pulling the session id's from there with a single query? looking at this, I almost added a method straight to the JDBCSessionIdManager but it feels like a one off hack and outside of a testing scenario I am not sure what use this has so am loathe to put it on the class itself. I have thought of a SessionTool interface that could be implemented on various implementations for a bit more information about these sorts of things but that again is mostly just for test purposes and would gobble up a bit more time then I have atm for general session issues. anyway, let me know if that would work for you, you wouldn't get the session info from jetty direct but it is available from the db... I am trying to sort out the jetty8 nightly repo as well
Oh, and I was poking around for ways you could know if the session was being created or not and you could also put a variable into the session that extends the HttpSessionActivationListener that would be notified on activation and passivation, so you could leverage that know see that the session was being loaded on the second node.
Thanks a lot Jesse for your replies. I understand your loath to pollute the SessionManager with methods only used in tests. Connecting directly to the database on the other hand ties our code to the details of Jettys session replication, which I don't like either. The HttpSessionActivationListener looks like a viable approach when in clustered mode. I will report here as soon as I have a working solution (or get stuck;)
The HttpSessionActivationListener approach doesn't work as I didn't find a way to register the listener at the (deserialized) session. Anyway, using a servlet filter does the trick. As in our environment only requests cause a session to get loaded/deserialized, the servlet-filter can keep track of all sessions. Thanks again.
