DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37356>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37356 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-08 21:16 ------- (In reply to comment #38) > Alright, since a workaround has been suggested and the original poster has not > come up with a reproducible test case, I'm closing this item for now. If the > original poster or anyone else comes up with a way to reproduce this, please > feel free to reopen this item, attach your new test case, and we will be glad > to > look at it. It sounds to me like the reproducible test case is the problem. It is pretty near impossible to provide the application, hardware configuration AND load necessary to reproduce this on a running instance of tomcat. In lieu of this, I propose a simple test case which reproduces in separate test code which closely mimics the behavior of tomcat. This behavior is essentially multiple requests in multiple threads accessing the int accessCount field in a session object. Each thread will increment the accessCount and then decrement it when the request completes. Here is some sample code to which basically does that: import java.util.concurrent.atomic.AtomicInteger; public class SharedIntTest { public AtomicInteger execCount = new AtomicInteger(); public AtomicInteger countAtomic = new AtomicInteger(); public int count; public static void main( String[] args ) { final SharedIntTest shared = new SharedIntTest(); int maxThreads = 1000; while ( true ) { //Initialize counters shared.countAtomic.set( 0 ); shared.execCount.set( 0 ); shared.count = 0; for ( int i = 0; i < maxThreads; i++ ) { new Thread( new Runnable() { public void run() { //increment counters shared.countAtomic.incrementAndGet(); shared.count++; //decrement counters shared.countAtomic.decrementAndGet(); --shared.count; //increment execution counter shared.execCount.incrementAndGet(); } } ).start(); } while ( shared.execCount.get() < maxThreads ) { try { Thread.sleep( 10 ); } catch( InterruptedException e ) { } } if ( shared.count != 0 ) System.out.println( "Count Error: " + shared.count + "/" + shared.countAtomic.get() + " " + shared.execCount.get() ); } } } The variable count basically represents the accessCount field in the session. In the body of the main method there is a while loop which repeatedly runs the test code. The test code initalizes all of the variables, and then launches a number of threads, which represent the requests in tomcat which are all incrementing and decrementing accessCount on a given session. All that the threads do is to increment the count variable and then immediately decrement it, basically what the request threads are doing in tomcat. The threads also increment a variable called execCount which is used to determine the number of completed threads. In the main thread, there is a loop which monitors the execCount to determine when all of the threads are completed. To make things interesting I have put an AtomicInteger counter in, countAtomic, to determine whether or not the Atomic solution mentioned in comment #21 would resolve the issue. When run on a single processor, this could runs continuously and never prints any errors, as we would hope. When I run this code on a dual processor, within a couple of minutes a test will run where the final result of the count variable is not zero. The countAtomic variable always has a final result of zero. In conclusion, I believe that Matthias Ernst in comment #35 is exactly right, either a sync must be done or Atomics must be used. Otherwise the session management code as it exists now will be very broken on multiprocessor machines. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
