tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT?] control of session timed out with tomcat
Date Fri, 21 Oct 2011 09:05:04 GMT
Mark Thomas wrote:
> 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 <>
>>>>>> 1) Tomcat (probably) doesn't spend its time all the time scanning
>>>>>> 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.

How about..

I am assuming that at each access to the application, Tomcat updates the expiration time 
of the session if any (that is, it sets a new date/time at which this session will be 
considered as expired, being "now" + timeout).

So Tomcat, at any time, could maintain an ordered list of sessions with their timeout 
timestamps (sorted by increasing expiration timestamp).

Now whenever the background thread goes into its "check for expired sessions" cycle, it 
could start at the beginning of the sorted list, and stop as soon as it encounters an 
entry with an expiration time which is later than "now", because any entry beyond that 
point is of course unexpired.

The sorted list needs to contain only the session-id and current expiration timestamp, so

it should not be that costly in terms of memory. (*)

In my personal experience, systems nowadays tend to be limited more by their disk I/O 
speed than by CPU usage.  Despite the more complex logic required by keeping the ordered 
list ordered, and considering that sessions are usually created/kept for a "considerable"

length of time, I have a feeling that this might provide a performance boost, all the more

important as the number of sessions increases.
Also, when checking a session for expiration, Tomcat would not actually need to read each

session's info to get its expiration time and decide to delete the session. It could just

check the entry in the list, and delete the session info immediately if it is expired, 
without needing to read it.

(*) I would even not be surprised if there existed already in memory some form of table 
representing the current sessions.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message