Note; this test is capable of fully saturating 4 CPU's to 100%.
[email protected] wrote:
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
