Craig R. McClanahan wrote: > > On Tue, 18 Jun 2002 [EMAIL PROTECTED] wrote: > > >>Date: Tue, 18 Jun 2002 16:56:29 -0400 (EDT) >>From: [EMAIL PROTECTED] >>Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> >>To: Tomcat Developers <[EMAIL PROTECTED]> >>Subject: [PATCH] When Session Max reached, throw out oldest session >> >> >>This PATCH implements the earlier PROPOSAL. namely; >> >> >>>PROPOSAL: When Session Max reached, throw out oldest session >>> >>>Currently tomcat ships with the maximum number of sessions set to >>>unlimited. They can expire by default after 30 minutes, however if >>>too many sessions are created within the 30 minutes, you can run out >>>of memory. >>> >>>To prevent running out of memory, you might choose to limit the >>>allowed number of active sessions. If you use the default >>>StanardManager (session manager) you can set the "maxActiveSessions" >>>to effect a limit. However if you exceed the number of allowed >>>sessions, a RuntimeException (IllegalStateException) is thrown. >>> >>>I propose two changes to reduce seeing these (IllegalStateException or >>>OutOfMemory) exceptions for sessions; >>> >>>1. When the maximum number of sessions is reached, change >>>StandardManager from throwing an IllegalStateException exception, to >>>expiring the Least Recently Used (LRUMap) session. >>> >>>2. Instead of defaulting to an unlimited number of sessions (and >>>getting visits from OutOfMemory), limit the number of sessions to >>>10000 by default. >> >>This PATCH does 1 and 2. It also fixes a problem with recycling >>sessions (manager was set to null before session could be recycled.) >> >>Can someone please review this? >> > > > I'm neutral on #2 (anyone who is really going to have that many sessions > is likely to be tuning lots of configuration parameters anyway), but I > don't think #1 is a good idea. > > Implementing it would be like running Jon's night club with the rule that, > when a new person came along, had the bouncer going in to kick out the > person whose beer is the warmest. It's probably better customer service > for the newcomer to wait until someone leaves voluntarily, which is how > the current algorithm works. :-) > > More seriously, you could force a DOS attack against an app that worked > this way, simply by continuously causing new sessions to be created. > Every real user that tried would get in, but only for one request. (You > can disrupt new users for an app based on the current algorithm, but you > can't cause any existing user to get kicked out.)
Ok, so maybe the behavior is bad in the default case, but the fact is the server may start working altogether without that (optional) limit. I like the idea of losing one session a bit better. The administrator would have to tweak that so that he would set the maximum value which would allow its server to run. OTOH, we could change it, and have the default be to have no limit. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
