[
https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814130#comment-15814130
]
TuoDi edited comment on AMQ-796 at 1/10/17 7:11 AM:
----------------------------------------------------
Yes,we have the some problem in activemq 5.10.0 and 5.13.4. we use failover tcp
protocol like:
failover://(tcp://127.0.0.1:61624,tcp://127.0.0.1:61626)?nested.wireFormat.maxInactivityDuration=3000&nested.connectionTimeout=2000&maxReconnectAttempts=2&timeout=2000&randomize=false&initialReconnectDelay=50&startupMaxReconnectAttempts=2&maxReconnectDelay=100
first keep all Mq server up
then shutdown one of the server
see the log keep create a new connection on the up server and then closed the
new connection and the recreate a new connection on the up server ...... dead
loop....
threaddump the thread and see the threadDump.txt and the test code Sender.java
in the attach file.
"ActiveMQ Task-1" daemon prio=6 tid=0x000000000d5c3800 nid=0x2bc8 waiting on
condition [0x000000000dc2e000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000db305ec8> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:97)
at
org.apache.activemq.transport.failover.FailoverTransport.restoreTransport(FailoverTransport.java:841)
at
org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1020)
- locked <0x0000000090c6a228> (a java.lang.Object)
at
org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:148)
- locked <0x0000000090c6a238> (a java.lang.Object)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
was (Author: tuodi):
Yes,we have the some problem in activemq 5.10.0 and 5.13.4. we use failover tcp
protocol like:
failover://(tcp://127.0.0.1:61624,tcp://127.0.0.1:61626)?nested.wireFormat.maxInactivityDuration=3000&nested.connectionTimeout=2000&maxReconnectAttempts=2&timeout=2000&randomize=false&initialReconnectDelay=50&startupMaxReconnectAttempts=2&maxReconnectDelay=100
first keep all Mq server up
then shutdown one of the server
see the log keep create a new connection on the up server and then closed the
new connection and the recreate a new connection on the up server ...... dead
loop....
threaddump the thread and see the threadDump.txt and the testcode Sender.java
in the attach file.
"ActiveMQ Task-1" daemon prio=6 tid=0x000000000d5c3800 nid=0x2bc8 waiting on
condition [0x000000000dc2e000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000db305ec8> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:97)
at
org.apache.activemq.transport.failover.FailoverTransport.restoreTransport(FailoverTransport.java:841)
at
org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1020)
- locked <0x0000000090c6a228> (a java.lang.Object)
at
org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:148)
- locked <0x0000000090c6a238> (a java.lang.Object)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
> Client may shtudown when failover connection is reconnecting. We need to
> maintain at least 1 non-daemon thread alive.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-796
> URL: https://issues.apache.org/jira/browse/AMQ-796
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 4.0, 5.3.0
> Reporter: Hiram Chirino
> Assignee: Rob Davies
> Fix For: 5.6.0, 4.0.3
>
> Attachments: AMQ-796.cmd, Sender.java, jstack_amq_5.6.0,
> jstack_v5.8.0, threadDump.txt
>
>
> Dejan Reported on the User lists:
> Hi,
> after some experiments I found that this problem only exists if there are no
> other threads in the application. It seems like connection thread dies
> before it manages to reconnect. By starting another thread in the
> application, it succeeds to recover from master failure and reconnect to the
> slave broker. So I have a workaround for now, but it would be nice to make
> this work even for simple (single-threaded) clients.
> Regards,
> Dejan
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
