RE: StandartSession.accessCount bug?
So what about this bug? When the fix will be out? -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Sunday, November 05, 2006 1:34 AM To: Tomcat Users List Subject: Re: StandartSession.accessCount bug? Christopher Schultz wrote: 150ns per request (on my hardware) is still probably more than we want to add to every request. Really? If you say so... Sorry. I was having a bad day. I was reading nano and thinking micro. Various performance figures show a 'fast' request takes about 100 micro seconds. Adding 150 micro seconds would be bad. However, 150ns per uncontended request is next to nothing. Adding 0.1% to the processing time is an easy choice in my book. 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: StandartSession.accessCount bug?
So you could use concurrency utilities as an external jar (back port from Java5) which is available for 1.4. They claim being able updating longs without locking java-level locks ... http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 2:32 PM To: Tomcat Users List Subject: Re: StandartSession.accessCount bug? Michael Kantarovich wrote: Guys, Did you consider to use java.util.concurrent.atomic.AtomicLong ? No, since this is a Java 5 class and TC5 will run on a 1.4 JVM providing a couple of additional JARs are present. 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StandartSession.accessCount bug?
Hi, I'm using version 5.5.12. I noticed that sometimes sessions doesn't expire after a session-timeout. I started to debug my application and when I haven't found anything useful I proceeded to Tomcat's code. It looks that there is a synchronization bug during the update of the StandardSession.accessCount. If I got it right, accessCount is a reference counter which propose is to prevent session from expiring while it's still in use. It's incremented when there is a Request which accesses it for the first time, and decremented when the Request is recycled. Suppose that my HTML generates several requests during the same session. Probably, those requests will be handled by different http-proccessor threads and those threads will try to increase/decrease the accessCount of the same Session simultaneously. This will cause statement ++/--accessCount in StandardSession.access/endAccess sometimes to use an old value ... What do you think? Thanks! Michael.
RE: StandartSession.accessCount bug?
Thanks! From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Tue 10/31/2006 3:22 AM To: Tomcat Users List Subject: Re: StandartSession.accessCount bug? Michael Kantarovich wrote: Hi, I'm using version 5.5.12. I noticed that sometimes sessions doesn't expire after a session-timeout. What do you think? That is http://issues.apache.org/bugzilla/show_bug.cgi?id=37356 I have some ideas for a fix. It might get in to 5.5.21 if I get the time to look at it some more. 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: StandartSession.accessCount bug?
Guys, Did you consider to use java.util.concurrent.atomic.AtomicLong ? From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Tue 10/31/2006 7:13 AM To: Tomcat Users List Subject: Re: StandartSession.accessCount bug? 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
