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)...
Pier
"Denis Benoit" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
