https://issues.apache.org/bugzilla/show_bug.cgi?id=43343
Konstantin Kolinko <knst.koli...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Severity|major |normal
--- Comment #9 from Konstantin Kolinko <knst.koli...@gmail.com> 2009-05-01
20:27:25 PST ---
I am reopening this issue, because:
1. The fix was not applied to TC 5.5, and the issue can be reproduced with TC
5.5.27.
2. The fix [1], as applied to 6.0 is not complete, though one may argue.
I am reducing severity to "normal".
The issue does not apply to the default configuration, where StandardManager is
used.
[1] http://svn.apache.org/viewvc?rev=656751&view=rev
On the issue:
When PersistentManagerBase swaps out a session it performs two actions (see its
implementation of swapOut()):
1. writing session data out
2. calling session.recycle() which invalidates the session
When session that is being used by an active request is being swapped out at
the same time (and what is the need for doing that? - you will not be able to
free the memory, because there is a reference), two races can occur:
Case A: request writes data to session at the same time as it is being written
out and before the recycle() call.
Result: the update is lost, next request will see the old values.
This is the case that is fixed by PersistentManagerBase patch in rev=656751
[1].
Case B: request accesses session after session.recycle(), e.g. after swapOut()
completes.
Result: java.lang.IllegalStateException: setAttribute: Session already
invalidated,
though the session was not invalidated, but just swapped out.
---------------------------------------------
Sample output from the client when Case A is observed (with TC 5.5.27):
Method failed: HTTP/1.1 500 Internal Server Error
Error (number=-1509748992, loop=140):
java.lang.IllegalStateException: Attribute loop is not equal to the expected
val
ue.
Expected: 139
Actual: 138
---------------------------------------------
Case B can be reproduced more easily if you replace
s/ if (false) { / if (true) { /
on line 57 in file index.jsp of the web application.
Sample output from the client when Case B is observed (current tc6.0.x, with
the mentioned change of line 57):
Method failed: HTTP/1.1 500 Internal Server Error
Error (number=-1309785265, loop=0):
java.lang.IllegalStateException: setAttribute: Session already invalidated
I have also seen the following NullPointerException when running against TC
5.5.27, and I think that it is the Case B:
The server encountered an internal error () that prevented it from fulfilling
this request.
exception:
org.apache.jasper.JasperException
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServle
tWrapper.java:460)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:373)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
root cause:
java.lang.NullPointerException
org.apache.catalina.session.StandardSession.setAttribute(StandardSession
.java:1309)
org.apache.catalina.session.StandardSession.setAttribute(StandardSession
.java:1248)
org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardS
essionFacade.java:130)
org.apache.jsp.index_jsp._jspService(index_jsp.java:88)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:331)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
---------------------------------------------
Case B can be solved by avoiding swapping out sessions that are owned by a
request. Synchronizing on a session is not sufficient.
A workaround is to avoid enabling IdleSwap in the configuration (it is disabled
by default).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
