On Thu, 2011-10-20 at 16:35 +0100, Mark Thomas wrote:
> On 20/10/2011 16:22, André Warnier wrote:
> > Hassan Schroeder wrote:
> >> On Thu, Oct 20, 2011 at 7:52 AM, André Warnier <a...@ice-sa.com> wrote:
> >>
> >>> 1) Tomcat (probably) doesn't spend its time all the time scanning stored
> >>> sessions to see if one has expired, and deleting it.
> >>
> >> Actually, it does. That's what session listeners depend on.
> >>
> >> So, for example, I can have a ShoppingCart with a method like
> >>
> >> public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
> >> {
> >>      empty(); /* remove reserved status from items */
> >> }
> >>
> >> If the session times out without the cart contents being purchased,
> >> the cart returns any items it contains to inventory. Very handy :-)
> >>
> > You mean that if there are 500 sessions active, Tomcat spends its time
> > checking all of them repeatedly on the off-chance that one has expired ?
> 
> It is handled by the background processing thread. By default that
> thread runs every 10 seconds and ManagerBase triggers a session
> expiration check every 6 runs by default. So in short, they are checked
> roughly every 60s. The test is pretty simple so it doesn't take very
> long at all.
> 
> > Or is there a smarter algorithm implemented there ?
> 
> Such as? I'm open to ideas here (maybe not for this exact problem but
> certainly the general one).
> 
Not necessarily claiming "better" but:
      * find the oldest session
      * go to sleep until it's ready to expire (since you know nothing
        interesting will happen before then)
      * wake up and expire sessions that need expiring
      * repeat

Of course, this would require a dedicated thread. If the background
thread handles more tasks than just expiring sessions there's probably
not much gain in doing this approach. Or you could use the 'find oldest
session' value to compute how many work cycles to skip until the next
actual check. Is the complexity worth the savings in CPU cycles? Eh,
probably a wash. Could set a minimum threshold and only use the computed
value if it's greater than the threshold. Incorporate the computation as
part of the session scan.

But you did ask... :-)

> Mark
> 
> ---------------------------------------------------------------------
> 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

Reply via email to