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 13:38:37 GMT
Mark,

>> Contended locks are much slower, so it's important to know.
>
> It was contended. I have added the uncontended figures: 75ns and 225ns.

What do the two different values mean?

Also, did your +50ns figure mean that the /overhead/ was +50ns, or that
waiting for the "other" thread to release the lock (which would include
execution of the method itself) took 50ms longer. Since those threads
cannot really run concurrently due to the synchronization, your timing
should be affected by that fact, instead of merely the added overhead.

> 150ns per request (on my hardware) is still probably more than we want
> to add to every request.

Really? If you say so...

>> Are Tomcat sessions pluggable?
>> [snip]
> 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.

Yeah, but there were people begging not to add another configuration
option. It's got to be a config option in either case.

> I agree it needs to be fixed. As do the other 180 odd currently open
> bugs ;)

Fair enough, but this one is easy. It's not like it's going to take
weeks of full-time work to develop and test a fix for this bug.

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

I understand the focus on performance, but this is a straight-up bug.
Their tag line ought not to be "Tomcat: doesn't work, but boy is it
fast". :(

-chris



Mime
View raw message