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?
Michael Kantarovich wrote: So what about this bug? When the fix will be out? The fix is in SVN now. It will be in 5.5.21. Release date for 5.5.21 is TBD. 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]
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]
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]
Re: StandartSession.accessCount bug?
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 signature.asc Description: OpenPGP digital signature
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]
Re: StandartSession.accessCount bug?
On Tue, Oct 31, 2006 at 08:38:37AM -0500, Christopher Schultz wrote: 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. uh.. I read that as 50 _m_s, not ns. eric - 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?
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]
Re: StandartSession.accessCount bug?
Mark, Mark Thomas wrote: 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 Wow. Some real yelling and screaming going on in that bug. Can someone explain why unsynchronized data + threaded access != non-threadsafe code? It doesn't take a genius to see that the accessCount variable there is not threadsafe. And since Tomcat ought to be implemented such that multiple threads can run successfully... WTF??! I'm not sure what source of the bitter animosity towards synchronization is in this case. Synchronization isn't a dirty word, especially when it actually makes things work properly :( -chris signature.asc Description: OpenPGP digital signature
Re: StandartSession.accessCount bug?
Christopher Schultz wrote: Can someone explain why unsynchronized data + threaded access != non-threadsafe code? It doesn't take a genius to see that the accessCount variable there is not threadsafe. And since Tomcat ought to be implemented such that multiple threads can run successfully... WTF??! I'm not sure what source of the bitter animosity towards synchronization is in this case. Synchronization isn't a dirty word, especially when it actually makes things work properly :( The problem is adding the sync hammers performance to the tune of about 50ms for every request (at least in my system - YMMV). 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. 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. 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]
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]
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]
