tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [PATCH] When Session Max reached, throw out oldest session
Date Wed, 19 Jun 2002 02:16:25 GMT
Agreed... If we start invalidating sessions when too much memory is
"wasted", I'm going to choose a different servlet engine for my 10m req/day
site... :) If I define that a session has a timeout, I want that timeout to
be _real_ and if I run into memory problems, well, that's my problem, not
yours (servlet engine developers)...


"Denis Benoit" <> wrote:

> It may not be as easy as it seems.  We don't need to preserve only the
> session ID, but any data that has been put in the session.  And I don't
> think there is a requirement in the specs for the data to be serializable.
> So a session that may have been "pushed" into secondary memory, may not,
> in certain cases, be fully restored or restored at all, save for the
> session identifier.  This may lead to difficult bugs to track if data
> suddenly seems to "disappear" from sessions.
> For my part, this is a tough call, I think the better way would be to
> deny the creation of a new session.  Like Craig, I don't think that
> "kicking out old sessions", is such a good idea, because it would appear
> to users that the site has an "elastic" timeout.  On a crowded server,
> users may very well start doing "blank" hits just to keep their sessions
> alive.  Now, more hits is not what you need on an already overloaded
> server :)  The best is to log the event: The deny of the creation of a
> new session.  Certainly a site that hits this wall needs to be resized,
> with either more memory or a new tomcat server in a "load balanced"
> pool.
> I don't think there will be a perfect answer.  For my part, I think the
> idea to impose a limit on the number of sessions is very good.  What I'm
> not comfortable with, is what we do once this limit is reached.  Whatever
> we do, it must make "sense" if we place ourselves in the shoes of a user
> of the server.  And if someone had already access to the server (an
> already established session), she shouldn't see a change of behavior
> because the server is temporarily seeing a burst of activity.  "You were
> kicked out, because somebody else got in."
> On Tue, 18 Jun 2002, Michael E. Locasto wrote:
>> I've done a bit of thinking and came up with a mechanism that might
>> solve both issues of wasted memory and "lost" users. It involves
>> persistent storage of "retired" sessions, so if this is actually how
>> LRUMap or the session Manager works, I apologize.
>> Basically, we should mimic a virtual memory type of mechanism. If a session
>> has not been used in a long time, we can store it out or "retire" it to file
>> system, dbase, ldap, etc...
>> In that way, we get some RAM back and do not "lose" the session. If a
>> request
>> for a session that is "retired" comes in (like a page fault), we can
>> retrieve it from disk.
>> Granted, this is more complex, and we face a possible new attack (requests
>> for retired sessions that are actually very very old or invalid). In
>> addition, a "session request fault" is not guaranteed to have enough memory
>> to bring the session back in.
>> Thoughts?

[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message