[
https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50352#action_50352
]
Freeman Fang commented on SM-1824:
----------------------------------
Just report this bug to SUN, need internal review before it is visible on the
Sun Developer Network (SDN).
> 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.2.3, 3.3
> 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"
> 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.
