Bugzilla – Full Text Bug Listing
| Summary: | Session Clustering with Database and FORM Authentication Broken | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Michael Malamud <mike.malamud> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | janb, jesse.mcconnell, jetty-inbox, mike.malamud |
| Version: | 7.1.3 | ||
| Target Milestone: | 7.1.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 328273 | ||
|
Description
Michael Malamud
I have updated the SessionAuthentication so that it the non serializable bits are transient. They are reestablished when the auth is deserialized. The test harnesses are not great for this part of the code. so it would be great if you could try a build after r2381. Also I'm uploading a build to http://oss.sonatype.org/content/repositories/jetty-snapshots/org/eclipse/jetty/jetty-distribution/7.2.1-SNAPSHOT This fix seems to have resolved the NotSerializable exception. I have witnessed the following behavior however: If I leave my system idle for a few hours, when I come back I see the following exception in the console window: 2010-10-22 11:03:44.342:WARN::Unable to load session from database java.lang.IllegalStateException: !SecurityHandler at org.eclipse.jetty.security.authentication.SessionAuthentication.readObject(SessionAuthentication.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.util.concurrent.ConcurrentHashMap.readObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(JDBCSessionManager.java:866) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:504) at org.eclipse.jetty.server.session.JDBCSessionManager.removeSession(JDBCSessionManager.java:728) at org.eclipse.jetty.server.session.AbstractSessionManager$Session.timeout(AbstractSessionManager.java:1039) at org.eclipse.jetty.server.session.JDBCSessionManager$Session.timeout(JDBCSessionManager.java:363) at org.eclipse.jetty.server.session.JDBCSessionManager.expire(JDBCSessionManager.java:784) at org.eclipse.jetty.server.session.JDBCSessionIdManager.scavenge(JDBCSessionIdManager.java:682) at org.eclipse.jetty.server.session.JDBCSessionIdManager.access$000(JDBCSessionIdManager.java:53) at org.eclipse.jetty.server.session.JDBCSessionIdManager$1.run(JDBCSessionIdManager.java:243) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) When the scavenge happens, there will be no current SecurityHandler, as no Context is in scope. We will need to rethink that logic. Possibly also the logic on the JDBC scavenge, as we are loading the session only in order to delete it - might make more sense to just delete it directly from the database in this case. Jan The JDBC load session is now called in the scope of a context handler In what version can I find the latest fixes for this issue? I just downloaded that package and noticed that after I unzipped it, in the /lib directory there are double .jar files for most of the jetty jars. I am seeing: jetty-ajp-7.2.0.v20101020.jar jetty-ajp-7.2.1-SNAPSHOT.jar jetty-annotations-7.2.0.v20101020.jar jetty-annotations-7.2.1-SNAPSHOT.jar etc... Should they both be there or only the jars ending with "-7.2.1-SNAPSHOT.jar" Thanks... Michael, That's odd. I've pushed a new snapshot. Try: http://oss.sonatype.org/content/repositories/jetty-snapshots/org/eclipse/jetty/jetty-distribution/7.2.1-SNAPSHOT/jetty-distribution-7.2.1-20101103.010751-6.zip thanks, Jan I am now seeing the following exception every couple of minutes or so: 09 Nov 2010 17:51:31.986 [qtp16821027-14] DEBUG org.eclipse.jetty.util.log - EOF org.eclipse.jetty.io.EofException: null at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:319) ~[jetty-http-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:212) ~[jetty-http-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426) ~[jetty-server-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:510) [jetty-io-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34) [jetty-io-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) [jetty-io-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:450) [jetty-util-7.2.1-SNAPSHOT.jar:7.2.1-SNAPSHOT] at java.lang.Thread.run(Unknown Source) [na:1.6.0_20] I am not sure what is causing this nor can I really debug much here... Michael, I think that might just be the normal EOF exception thrown when a client times out an idle connection and closes it. You are only seeing it because debug is turned on. |