-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 10/20/2011 11:35 AM, Mark Thomas wrote:
> On 20/10/2011 16:22, André Warnier wrote:
>> 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).

I suppose one could use a (inverse?) priority queue where the priority
is the last session touch time. When a session is touched, it's place
in the queue is adjusted. When it's time to cull the sessions, you
linearly process the queue until you hit a session that does not
require expiration, and you're done.

Use of a priority queue might end up being less efficient than the
current implementation, especially when considering the cost of
synchronization for shuffling sessions around in the queue (on every
request!) and then getting an exclusive lock for the session-reaper
which may last a non-trivial amount of time.

I suspect session events are triggered directly by the background
thread, and not delegated to another thread, so a long-running
valueUnbound job could hold-up the entire container.

I didn't say it was a good idea... only that is was AN idea :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6gieQACgkQ9CaO5/Lv0PBQ9ACeMVOxFI7tp5HnJ2QYM5R3X9y+
6kYAnRZM2OUQqtMYrwTStrZLK5fPjJ7/
=LYNt
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to