BUG in JDK6  ReentrantReadWriteLock can cause SMX hang when redeploy SA
-----------------------------------------------------------------------

                 Key: SM-1824
                 URL: https://issues.apache.org/activemq/browse/SM-1824
             Project: ServiceMix
          Issue Type: Bug
    Affects Versions: 3.3, 3.2.3
         Environment: Java version: 1.6.0_06
OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix"
            Reporter: Freeman Fang


Look at this test code 
{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();
            }

        }

    }
}

{code}

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.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to