This is more-or-less what we've done. It seems to work for our situation. We've added some variables to the DeltaManager config, so we can control the behavior as well. We can now set the minimum "threshold" for a session duration, where sessions less than this threshold will not get replicated in any case. (From my perspective, this just makes sense - if the session duration is small enough, and your system is busy enough - replicating make introduce more delay than the session has to live. For example, in our load testing, we're seeing session replication lagging behind session creation by several seconds. If a given session is shorter than the lag, it would never make sense to replicate it anyway.)
-- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -----Original Message----- From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] Sent: Wednesday, January 13, 2010 2:12 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration The sensible approach would be 1. Refactor DeltaManager and BackupManager to defer the session creation message until the request is complete 2. Then simply swap out the ReplicationValve with an implementation that makes sense Filip On 01/12/2010 11:42 AM, Robin Wilson wrote: > REPOSTING this so it won't be on the other thread - sorry about that. > > 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.) > > 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. 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. > > 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). > > -- > Robin D. Wilson > Director of Web Development > KingsIsle Entertainment, Inc. > CELL: 512-426-3929 > DESK: 512-623-5913 > www.KingsIsle.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
