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]

Reply via email to