tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Date Tue, 12 Jan 2010 22:27:54 GMT
On 12/01/2010 21:05, Christopher Schultz wrote:
> Hash: SHA1
> Robin,
> On 1/12/2010 1:42 PM, Robin Wilson wrote:
>> Earlier this week I posted a question about how to prevent sessions
>> from being created in our Tapestry pages, and/or how to get Tomcat to
>> get rid of a bunch of '1-second' sessions we're creating during a
>> load test because the sessions eventually fill up the heap. (They are
>> being created faster than Tomcat can clean them out - even though
>> they expire faster than we create them.)
> Well, they are eligible for expiration faster than they are being
> created. That session expiration thread can't be running /all/ the time :)
>> So, my lead developer thinks he has found a way to alleviate our
>> problems (at least for our production Tomcat 6.0.20 cluster of 4
>> servers). We will not replicate sessions to other cluster members
>> unless they have a duration longer than a 'threshold' we set.
> Aah... I didn't realize that you were experiencing a session replication
> "storm" in your test setup. I thought you were only using a single app
> server for load testing. Did I misunderstand?
>> We are
>> altering the DeltaManager to make this change, so that simply
>> creating a session doesn't automatically guarantee that it is
>> replicated to other nodes in the cluster. The session duration will
>> also have to be greater than a "sessionDurationMinThreshold" value we
>> will set in the 'server.xml' file for the new DeltaManager. The idea
>> is that sessions created that have very short durations are really
>> 'transient' anyway, so there is no need to pass them off to the other
>> members of the cluster.
> One could argue that sessions limited to that length of time are not
> necessary at all. Why bother creating them in the first place?
>> The question I have, is there anything we should watch out for in
>> making this adjustment to the DeltaManager? We will test this pretty
>> heavily before we deploy it to our production environment, but I'm
>> worried about things we should be looking for in that testing (other
>> than just validating that our "useful" session data can be available
>> across multiple cluster members).
> Give some of the cluster gurus on the list a chance to read your
> question. Feel free to start your implementation: I'm guessing it's a
> pretty simple change to simply ignore sessions with low timeouts.
> Depending on how to set up your sessions, you may not be able to prevent
> the replication (or replication of "useful" sessions may not occur).
> I've never looked at the code for the DeltaManager, but I can imagine a
> scenario like this:
> 0. Your web.xml configures the default session timeout to be 1 second
> 1. Upon session creation, DeltaManager is notified that a session
>     has been created and will need to be replicated
> 2. DeltaManager sees that the "sessionDurationMinThreshold" is only 5s,
>     and so it decides not to replicate that session throughout the
>     cluster
> 3. Your code (still during the request that created the session)
>     determines that this will be a useful session and changes the
>     timeout, say, to 30 minutes
> Result: a useful session is never replicated
> Conversely, the opposite situation could occur if your default timeout
> is 30 minutes and you intentionally reduce the timeout for sessions
> expected to be useless: in this case, replication occurs all the time.
> Beware!

If you can't stop the session from being created, storing a value in the 
session to indicate whether the session should be replicated might be 
easier to manage & monitor than juggling variable session times.


> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAktM5B4ACgkQ9CaO5/Lv0PDj5wCfZ4CGx2XZbq+qsFx9/GVK6eCy
> 6HQAoJvD81ghtJl7L9KGCvKyTXN9LF0j
> =2nq7
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message