DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42691>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42691 Summary: sessions increase timeout as cluster members join Product: Tomcat 5 Version: 5.5.23 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina:Cluster AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is probably not a big problem for most users of session replication. However for us it was worth fixing. In our environment we commonly perform rolling software upgrades across our web site. While testing replication, we noticed that as we shutdown and restarted nodes, the session counts would continually grow. Basically, we found that as sessions are transfered at startup time, the local access time is set to the transfer time. Code comments imply that this is done to prevent incorrect node time synchronization problems. However, it also simulates activity for old sessions that are about to expire. Under load, if you restart nodes enough, your session count will keep growing and growing. We changed the current behavior to keep existing session access times by commenting out the call to session.access() in DeltaManager.deserializeSessions (line 782 in svn revision 548361) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
