You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Prashant Rao <pr...@firstrain.com> on 2001/10/13 22:26:09 UTC

FW: StandardSession Management

Hi 
	I am currently working on a product using tomcat3.2 as a servlet
engine.  The product i am working on is computationally intensive.  The
tests conducted for the product included a stress test using a web
stress testing tool that continuously sent requests to the server as
long as the server could handle them (Microsoft WAS tool ). There were
about three-to-five threads for the different tests constantly sending
requests to the server.  Each new request creates a new session since
cookies were turned off.  The session-time out  was set at 1 minute in
the tomcat web.xml as well as the web.xml file in the application (under
webapps/appname/WEB-INF)

	The average statistics showed that the number of sessions on the
server grew continuously for the duration of the test.  Though the
session-time out was set for one minute.  But as soon as the stress
thest was stopped the house keeping thread (StandardManager) started to
drop all the sessions.  In fact the number of sessions created are so
large (go into thousands)(with the throughput that the product has and a
1 minute time out the number of valid sessions should have been around
400-to-500) that the sessions are serialized and once the stress test
ended the sessions were deserialized and then nuked.  The product
attaches some of the objects to the session by implementing
sessionBinding listener.  Thus if a session is not dropped valuable
resources are held up.  Can some one suggest as to why this his
happening ?

	Also as an understandable outcome (since the sessions are not
dropped some of the objects associated with the session are in the heap)
the java heap size grew considerably.  Ultimately it exceeded the
default java heap size of the OS (MS-2000) and the server stopped with
an out-of-memmory exception.  

Can some one please shed some light on this behavior.  Does the
StandardManager thread run on an low priority ? Is there some way to
bump up the priority of the StandardManager.  Is there some settings not
being used properly (The timeout seems to be o.k. as all the sessions
begin to get dropped as soon as the stress test ends.)

Any suggestions are welcome .

Regards 
Prashant