You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2009/03/09 13:13:39 UTC
[jira] Created: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
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.
[jira] Updated: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated SM-1824:
-----------------------------
Component/s: servicemix-core
Fix Version/s: 3.2.4
3.3.1
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50942#action_50942 ]
Freeman Fang commented on SM-1824:
----------------------------------
http://svn.apache.org/viewvc?rev=760773&view=rev
use ReentrantReadWriteLock from Apache Harmony for 3.2 branch
> 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
> Assignee: 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50914#action_50914 ]
Freeman Fang commented on SM-1824:
----------------------------------
Did a quick test with using ReentrantReadWriteLock from backport-util-concurrent-2.2.jar, no luck. Both jdk 5 and jdk6 hang. Seems the ReentrantReadWriteLock from backport-util-concurrent-2.2.jar is not what we want.
Will try the one from Apache Harmony
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50486#action_50486 ]
Ron Gavlin commented on SM-1824:
--------------------------------
Hi Freeman,
Is there a way to work-around this bug until a patch for this issue can be incorporated into JDK 6? An SMX bus hang on SA redeployment is a serious problem from my perspective.
/Ron
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50945#action_50945 ]
Freeman Fang commented on SM-1824:
----------------------------------
Just test and verify that for smx 3.3, with the appeded patch, don't use flow.suspend(which in turn don't use Reentrant writelock), redeploy SAs is ok, and not hang for both jdk5 and 6.
> 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
> Assignee: Freeman Fang
> 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.
[jira] Updated: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated SM-1824:
-----------------------------
Attachment: SM-1824.patch
> 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
> Assignee: Freeman Fang
> 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.
[jira] Resolved: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated SM-1824:
-----------------------------
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"
was:
Java version: 1.6.0_06
OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix"
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50464#action_50464 ]
Freeman Fang commented on SM-1824:
----------------------------------
SUN just confirm this bug, we get bug id now
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6816565
NOTE: It may take a day or two before this bug shows up in this link
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50868#action_50868 ]
Guillaume Nodet commented on SM-1824:
-------------------------------------
I think we discussed this issue on IRC ...
I don't think the api javadoc does not really explicitely defines the behavior when readLock and writeLock are trying to be acquired at the same time.
Anyway, in smx 3.3 + the new endpoint / assembly behavior (where stopping the sa waits for all exchanges to be processed), the lock may not be needed anymore.
It needs a bit more investigation.
> 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.
[jira] Commented: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50915#action_50915 ]
Freeman Fang commented on SM-1824:
----------------------------------
yeah ReentrantReadWriteLock from Apache Harmony works by my initial test
> 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.
[jira] Assigned: (SM-1824) BUG in JDK6 ReentrantReadWriteLock can
cause SMX hang when redeploy SA
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang reassigned SM-1824:
--------------------------------
Assignee: Freeman Fang
> 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
> Assignee: 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.