[ 
https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Fang resolved SM-1824.
------------------------------

    Resolution: Fixed

commit fix
http://svn.apache.org/viewvc?rev=760819&view=rev for trunk

> 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
>          Components: servicemix-core
>    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
>            Assignee: Freeman Fang
>             Fix For: 3.3.1, 3.2.4
>
>         Attachments: SM-1824.patch
>
>
> 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