Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.3, 3.3
    • Fix Version/s: 3.2.4, 3.3.1
    • Component/s: servicemix-core
    • Labels:
      None
    • Environment:

      Java version: 1.6.0_12 and 1.6.0_06
      OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix"

      Description

      Look at this test code

      import java.util.concurrent.locks.*;
      import java.util.concurrent.*;
      
      /**
       * Test ReentrantReadWrite Lock.
       * This code shows how we cannot get a read lock if the sequence is
       * thread 1:  rwlock.readLock().lock(); //should sucess to get the readLock
       * thread 2:  rwlock.writeLock().lock();//should fail to get the writeLock since the readLock already hold by another thread
       * thread 3: rwlock.readLock().lock(); //should success to get the readLock since no other thread hold the writeLock but failed only with JDK6, (OK with JDK 5)
       */
      public class TestTryWriteInRead {
      
          void log(String s) {
              System.out.printf("%s: %s%n", Thread.currentThread().getName(), s);
          }
      
      
          public static void main(String[] args) throws Exception {
      
              new TestTryWriteInRead().runTest();
          }
      
          public void runTest() throws Exception {
              ReentrantReadWriteLock rwlock = new ReentrantReadWriteLock(false);
      
              // obtain read lock
              rwlock.readLock().lock(); //should sucess to get the readLock
      
              // start 1 threads
              for (int i = 0; i < 1; i++) {
                  new Thread(this.new WriteLockThread(rwlock), "TryWrite" + i).start();
                  Thread.sleep(3000);
                  new Thread(this.new ReadLockThread(rwlock), "TryRead" + i).start();
              }
          }
      
          class WriteLockThread implements Runnable {
      
              private ReentrantReadWriteLock rwlock;
      
              public WriteLockThread(ReentrantReadWriteLock rwlock) {
                  this.rwlock = rwlock;
              }
              public void run() {
                  try {
                      log("try get writelock");
                      rwlock.writeLock().lock(); //should fail to get the writeLock since the readLock already hold by another thread
                      log("can get writelock"); // can't print out
                  } finally {
                  }
      
              }
      
          }
      
          class ReadLockThread implements Runnable {
      
              private ReentrantReadWriteLock rwlock;
      
              public ReadLockThread(ReentrantReadWriteLock rwlock) {
                  this.rwlock = rwlock;
              }
              public void run() {
                  try {
                      log("try get readlock");
                      rwlock.readLock().lock();//should success to get the readLock since no other thread hold the writeLock but failed only with JDK6, (OK with JDK 5)
                      log("can get readlock");//get this print out with JDK5 as expected, but not with JDK6, which means the error in JDK6
                  } finally {
                      log("unlock readlock");
                      rwlock.readLock().unlock();
                  }
      
              }
      
          }
      }
      
      

      Run this code with JDK 5 we get the expected behavior , the console output is
      TryWrite0: try get writelock
      TryRead0: try get readlock
      TryRead0: can get readlock
      TryRead0: unlock readlock,
      rwLock.readLock() can get readLock in trhead with name TryRead0
      But run this code with JDK 6 we get console output like
      TryWrite0: try get writelock
      TryRead0: try get readlock
      which means can't get readLock even there is no other thread hold the writeLock, that's conflict with the JDK API DOC.

      Actually this test code is the abstraction of the behavior when we redeploy SAs, especially at the same time externel client still send message to the endpoint.
      We can find the ReentrantReadWrite used in AbstractFlow, and in some case if the ReentrantReadWrite read and write lock accquire seqence is same as the test code, then the SMX bus hang.

      1. SM-1824.patch
        5 kB
        Freeman Fang

        Activity

        Freeman Fang created issue -
        Freeman Fang made changes -
        Field Original Value New Value
        Environment Java version: 1.6.0_06
        OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix"
        Java version: 1.6.0_12 and 1.6.0_06
        OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix"
        Freeman Fang made changes -
        Assignee Freeman Fang [ ffang ]
        Freeman Fang made changes -
        Attachment SM-1824.patch [ 17869 ]
        Freeman Fang made changes -
        Fix Version/s 3.3.1 [ 11978 ]
        Fix Version/s 3.2.4 [ 11990 ]
        Component/s servicemix-core [ 11510 ]
        Freeman Fang made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Maciej Prochniak made changes -
        Link This issue is related to SM-1868 [ SM-1868 ]
        Jeff Turner made changes -
        Project Import Sat Nov 27 00:46:19 EST 2010 [ 1290836779991 ]

          People

          • Assignee:
            Freeman Fang
            Reporter:
            Freeman Fang
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development