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
