[jboss-cvs] JBossAS SVN: r87535 - branches/Branch_5_x/testsuite/src/main/org/jboss/test/cluster/defaultcfg/test.

[jboss-cvs-commits at lists.jboss.org]

Author: bstansberry at jboss.com
Date: 2009-04-19 13:14:29 -0400 (Sun, 19 Apr 2009)
New Revision: 87535

Modified:
   branches/Branch_5_x/testsuite/src/main/org/jboss/test/cluster/defaultcfg/test/ReadWriteClusteredLockManagerUnitTestCase.java
Log:
Deal with race condition in testConcurrentRemoteLock

Modified: branches/Branch_5_x/testsuite/src/main/org/jboss/test/cluster/defaultcfg/test/ReadWriteClusteredLockManagerUnitTestCase.java
===================================================================
--- branches/Branch_5_x/testsuite/src/main/org/jboss/test/cluster/defaultcfg/test/ReadWriteClusteredLockManagerUnitTestCase.java	2009-04-19 13:48:14 UTC (rev 87534)
+++ branches/Branch_5_x/testsuite/src/main/org/jboss/test/cluster/defaultcfg/test/ReadWriteClusteredLockManagerUnitTestCase.java	2009-04-19 17:14:29 UTC (rev 87535)
@@ -145,6 +145,22 @@
       verify(handler);      
    }
    
+   /**
+    * Test for handling concurrent calls to remoteLock when the lock
+    * is in UNLOCKED state. Calls should get passed to the local lock handler,
+    * which allows one to succeed and the other to throw a TimeoutException;
+    * testee should react correctly.
+    * 
+    * FIXME We are using a MockObject for the LocalLockHandler impl, and with
+    * that approach we can't really get concurrent calls to it. Effect is 
+    * sometimes the thread that acquires the lock has already done so before
+    * the other thread even invokes remoteLock, defeating the purpose of this
+    * test and turning it into a variant of testContestedRemoteLock. Need to redo
+    * this test with a true multithreaded local lock handler, updating the latches
+    * such that both threads are in BlockingAnswer.answer at the same time.
+    * 
+    * @throws Exception
+    */   
    public void testConcurrentRemoteLock() throws Exception
    { 
       TesteeSet<NonGloballyExclusiveClusterLockSupport> testeeSet = getTesteeSet(node1, 1, 3);
@@ -169,7 +185,13 @@
       handler.lockFromCluster("test", caller1, 1000);
       expectLastCall().andAnswer(caller1Answer); 
       handler.lockFromCluster("test", caller2, 1000); 
-      expectLastCall().andAnswer(caller2Answer);    
+
+      
+      // There is a race where t1 may have already marked the lock as LOCKED in 
+      // which case t2 will not call handler.lockFromCluster("test", caller2, 1000);
+      // See FIXME in method javadoc. So, we use times(0, 1) to specify no
+      // calls are OK
+      expectLastCall().andAnswer(caller2Answer).times(0, 1);    
       replay(handler);
       
       CountDownLatch startLatch1 = new CountDownLatch(1);
@@ -209,8 +231,11 @@
          assertEquals(RemoteLockResponse.Flag.OK, rsp.flag);
          assertNull(rsp.holder);
          
-         rsp = loser.getResult();         
-         assertEquals(RemoteLockResponse.Flag.FAIL, rsp.flag);
+         rsp = loser.getResult();     
+         if (rsp.flag != RemoteLockResponse.Flag.REJECT)
+         {
+            assertEquals(RemoteLockResponse.Flag.FAIL, rsp.flag);
+         }
          assertEquals(caller1, rsp.holder);
       }
       finally