-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Emerson,
On 10/11/2010 8:54 AM, emerson wrote: > Thousands of Session instances inside the sessioins attribute of the > org.apache.catalina.session.StandardManager. > In theory we are not calling getSessions on the middle tier and as you > mentioned, we have no JSPs either. Okay, so you have lots of HttpSession objects being created. :( > However, we might be passing a jsession parameter from the frontend to > the middle tier. Would that be an issue, causing the session to be > created in the middle tier? That shouldn't affect anything: Tomcat will only create an HttpSession object if the code requests one. The client cannot force the creation of a session. That would be a pretty big DoS vulnerability. >>> What is the impact of using session-timeout = 0? >> >> Your sessions will never time out, and your problem will likely get worse. > > In the only place I see any reference to it is here: > http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/session/StandardSessionFacade.html#setMaxInactiveInterval(int) > > And it says that "A negative time indicates the session should never > timeout.". there is no mention about setting as "0". I thought I looked that up when I responded, but apparently I didn't. It's covered in SRV.7.5 of the servlet spec (v2.5) and you're right: -1 means "never time out" while 0 presumably means "expire as soon as possible". The best way to find out what code is generating the sessions is to install an HttpSessionListener. I know that I've posted code previously to this list that will emit a stack trace to the application log when a session is created. You could look that up or simply write one from scratch. Hint: it's next to trivial to implement this. Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0z5oACgkQ9CaO5/Lv0PAY4QCgnTEcs/uIrDr8Gl7O4tPPwoTM TKgAoMI2GAqXSPvMMFvsYOkqrd6klb4o =BhGS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
