On 5/2/2012 2:17 PM, Caldarale, Charles R wrote:
Both this symptom and your earlier one about creating a session after a
response has been committed are representative of the kinds of errors seen when
a webapp stores references in an inappropriate scope. For example, keeping a
reference to a request or response object in a static field, a session, or a
thread-local, will often result in the wrong object being used later on. This
is especially evident under high-load situations...
- Chuck
Thanks, Chuck. I know you are an expert here. That could be since it's
very odd to have all of these different sorts of exceptions occurring on
what should be standard JSP/servlet code, as if my
request/response/session objects are messed up.
That being said, our "PageBean" class associated with our JSPs are all
at the 'request' scope:
<jsp:useBean id="bean" scope="request"
class="org.example.PlayerRegistration2Page" />
The PageBean holds a reference to the request, response and session
objects, as defined in the JSP's java code, but we are passing in the
standard objects our page should be getting from Tomcat:
bean.init(session,request,response);
I am pretty sure we never store the request/response objects in the
session, static field or thread-local. So once a response is sent back,
it seems that our PageBean class should fall out of scope as it was tied
into the request scope.
We have implemented our own HttpSessionListener so we can track
sessionCreated and sessionDestroyed events. So I am saving the session
objects between the two events which we use to show "all active users"
including the session start time and last accessed time (which is why we
store the actual session object). We started 13,350 sessions during
the test, with a max of 1800 concurrent sessions. But we don't seem to
have trouble keeping track of them because now that the testing is done,
we can see just the current user sessions listed (in this case, just
two, both started recently), so all of those sessions eventually ended
or expired and were then removed from our tracking list.
Is it possible that if we keep a handle on the session (though we remove
that on sessionDestroyed) this prevents Tomcat from some sort of GC
issue with respect to the sessions?
Your thoughts on this are much appreciated.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
