Christopher Schultz wrote:
> 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.
It was contended. I have added the uncontended figures: 75ns and 225ns.

> 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.
150ns per request (on my hardware) is still probably more than we want
to add to every request.

> 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.
That would work. However (and this is just my view) making it an
optional feature of the standard implementation would be less work,
easier to maintain and less prone to user configuration error.

> 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.
I agree it needs to be fixed. As do the other 180 odd currently open
bugs ;) Performance is something that does get a fair amount of
attention from the Tomcat committers and the fix for this needs to
keep that in mind.  From my perspective this is a feature/performance
trade-off where we can provide a configuration option for users to
make their own decision.

Mark

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to