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=37356>. 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=37356 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-09 14:24 ------- (In reply to comment #44) > Very funny. Adding two syncs part of every request just to provide support > for a > really stupid feature is not acceptable. I don't know about calling it "really stupid". Non-standard and not well tested, certainly. Plus, since Sun points at Tomcat as the reference implementation of the Servlet spec, extensions like this should be eliminated as a matter of course. In my humble opinion, of course. =) > The actual options are: > - remove the "no expire while requests are in progress" feature by default, > with > an option to use the feature with full syncs for the two people that actually > need it > - force expire of abnormally long sessions regardless of the accessCount value > (many times over the session expiration time, with a minimum amount of time > of a > few hours) Both of those options are also "very funny". Please don't clutter up the code with yet another config option. Kill the feature and make folks who want it resort to a Filter or a Valve or something. The thought of adding code to look at sessions with nonzero accessCounts and arbitrarily killing off sessions after "many times over the expiration time" has passed ... yuck. A bug to fix a bug, now that's non acceptable. =P -- 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]