> > > > 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. :-)
Sessions, or server memory, is a limited resource. So no matter how you slice it your bar isnt going to be able to please everybody. This proposal/patch allows the sober guy to enter and escorts the had too much guy out. > 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.) Interesting... well the DOS attack would constantly creating new sessions... but active users of the site would, because they are using the site, would be moved up to the top of the LRU, so the least used sessions would be ones being deleted... which would probably be the ones from the DOS program (unless it was smart enough and had enough memory to keep track of all the sessions it was making, and it refreshed its cookies/sessions at the right times..) So depending on the parameters and rate of DOS, this algorthim might actually reduce the effect of a DOS attack. Cheers, -bob -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
