[
https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50913#action_50913
]
Freeman Fang commented on SM-1824:
----------------------------------
After hava chat with Guillaume, the possible workaround of this issue for smx
3.2 is use Reentrant lock from Apache Harmony instead the one from Sun JDK.
And for smx 3.3, since SU honor the stop state (i.e. process exchanges, but do
not consumer new external exchagnes), when stopping the SA in smx 3.3, the
container will wait for all exchanges to be processed before shutting it down.
So we get chance to remove Reentrant writelock, although this need a liitle
bit more test.
I will test both of it.
> 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.
