On 20/10/2011 17:01, Tim Watts wrote:
> 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
This can change dynamically since application code can change the
session expiration time at any point.
> * 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... :-)
If session expiration time was constant, this would be fine.
Unfortunately, that is not the case.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
