tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Wall <d.w...@computer.org>
Subject Re: Tomcat 7 - No modifications are allowed to a locked ParameterMap
Date Wed, 02 May 2012 21:43:47 GMT


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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message