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