tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: StandartSession.accessCount bug?
Date Tue, 31 Oct 2006 04:44:58 GMT
Mark,

> The problem is adding the sync hammers performance to the tune of
> about 50ms for every request (at least in my system - YMMV).

I posted a comment on that bug that points out that you didn't provide
context for your numbers. Was that +50ms timing taken when you were
using a single thread, or multiple threads? Contended locks are much
slower, so it's important to know.

If the overhead of synchronization is +50ms for "busy" sessions, but
lower for mostly idle sessions, then the fix is much more acceptable. I
just prefer that people actually do benchmarks instead of crying about
what they think might happen.

Thanks for finally posting the only performance numbers anyone mentioned
in that bug. :(

> The other part of this is that accessCount is there to support a
> reasonably rare use case where a single request can last longer than
> the session timeout.

But it's apparently a very useful feature on which some people depend. I
actually thought it was a good idea to add that "in-use" safety feature.
Perhaps a better solution would be to allow a magic session attribute to
be set which would cause Tomcat to wait on session expiry. For example:

session.setAttribute(TomcatConstants.DONT_KILL_MY_SESSION,Boolean.TRUE);
//
// do something that takes forever, like sending a 1TB file to
// the remote user
//
session.removeAttribute(TomcatConstants.DONT_KILL_MY_SESSION);

Just make sure that you access the session in a thread safe way... oh,
wait. You can't. :(

> Currently, I am in favour of adding the syncs but making the use of
> accessCount (and hence the syncs) optional with the default set to not
> use accessCount. Those that need this feature but don't want the
> performance hit of syncs are then free to implement their own solution
> within their application specific to their circumstances.

Are Tomcat sessions pluggable? Meaning, can you swap-out the
implementation of the
SessionManager/StandardSession/StandardSessionFacade classes using a
system property or other config option? If so, then this is a
no-brainer: ship Tomcat with the current implementation (minus the
accessCount) as the default. Then, provide an implementation /with/
accessCount, and with sync'd accessCount. They could all extend each
other so there wouldn't be a bunch of duplicated code.

For me, it's not about performance. It's about things working properly.
I realize that performance matters when you're dealing with billions of
requests per hour, but if you really are serving that many requests per
hour, you're going to get fux0rd by this bug anyway. It just needs to
get fixed.

-chris


Mime
View raw message