Author: peter_firmstone Date: Sun Mar 10 06:04:40 2013 New Revision: 1454793
URL: http://svn.apache.org/r1454793 Log: Mux field defaultTimout was written by threads synchronizing on ConnectionManager's lock during startup, however reads were performed while holding muxLock. The documentation stated that access to defaultTimeout was unsynchronized. The failing test: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Suspected cause: because reads and writes were synchronized on different locks and defaultTimout was neither final nor volatile, threads could see defaultTimeout in it's default constructed state of 0, causing an IOException: [java] TestBase.fail FINE: WriteTask_190: Caught an unexpected Exception during a retry [java] java.rmi.ConnectIOException: I/O exception connecting to BasicObjectEndpoint[b3755737-cdf3-49d7-adb1-33197bc3a993,TcpEndpoint[10.1.1.2:54176]]; nested exception is: [java] java.io.IOException: timeout waiting for server to respond to handshake [java] at net.jini.jeri.BasicInvocationHandler.wrapSafeIOException(BasicInvocationHandler.java:893) [java] at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:711) [java] at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659) [java] at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528) [java] at com.sun.jini.outrigger.$Proxy1.write(Unknown Source) [java] at com.sun.jini.outrigger.SpaceProxy2.write(SpaceProxy2.java:296) [java] at com.sun.jini.test.impl.outrigger.matching.StressTest$WriteRandomEntryTask.spaceWrite(StressTest.java:585) [java] at com.sun.jini.test.impl.outrigger.matching.StressTest$WriteRandomEntryTask.run(StressTest.java:548) [java] at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331) [java] Caused by: java.io.IOException: timeout waiting for server to respond to handshake [java] at com.sun.jini.jeri.internal.mux.MuxClient.newRequest(MuxClient.java:68) [java] at net.jini.jeri.connection.ConnectionManager$OutboundMux.newRequest(ConnectionManager.java:391) [java] at net.jini.jeri.connection.ConnectionManager$ReqIterator.next(ConnectionManager.java:665) [java] at net.jini.jeri.BasicObjectEndpoint$1.next(BasicObjectEndpoint.java:370) [java] at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:708) [java] ... 7 more I was reliably able to reproduce this on Solaris 10 sparc, 4 x 450MHz Ultra 80 with interleaved Ram. java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode) Changing the field to volatile (state wasn't dependant on previous state and wouldn't cause deadlock) fixed the issue. Modified: river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java Modified: river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java URL: http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java?rev=1454793&r1=1454792&r2=1454793&view=diff ============================================================================== --- river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java (original) +++ river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java Sun Mar 10 06:04:40 2013 @@ -137,7 +137,9 @@ abstract class Mux { final Map sessions = new HashMap(5); private int expectedPingCookie = -1; - private long startTimeout = 15000; // milliseconds + + /** unguarded instance state */ + private volatile long startTimeout = 15000; // milliseconds /** * Constructs a new Mux instance for a connection accessible through
