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
