qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Rudyy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-8222) [JMS AMQP 0-x][AMQP 0-8..0-91] Transaction commit/rollback or recover can hang when failover is in progress
Date Thu, 02 Aug 2018 11:52:00 GMT

    [ https://issues.apache.org/jira/browse/QPID-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566665#comment-16566665

Alex Rudyy commented on QPID-8222:

The easiest way to reproduce the issue is to configure open transaction timeout on broker
side, start producing transaction, wait for the timeout to expire and try to commit the transaction.

> [JMS AMQP 0-x][AMQP 0-8..0-91] Transaction commit/rollback or recover can hang when failover
is in progress
> -----------------------------------------------------------------------------------------------------------
>                 Key: QPID-8222
>                 URL: https://issues.apache.org/jira/browse/QPID-8222
>             Project: Qpid
>          Issue Type: Bug
>          Components: JMS AMQP 0-x
>    Affects Versions: qpid-java-6.1.6, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1,
qpid-java-6.1.2, qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-client-0-x-6.3.0,
qpid-java-6.1.5, qpid-java-client-0-x-6.3.1, qpid-java-client-0-x-6.3.2
>            Reporter: Alex Rudyy
>            Priority: Blocker
>             Fix For: qpid-java-client-0-x-6.3.3
>         Attachments: thread-dump.txt
> JMS transaction commit/rollback or recover can hang when connectivity is lost and failover
is triggered to restore the connection. When commit/rollback/recover are invoked after restoring
the connectivity and before failover finishes resubscribing of existing sessions, the syncing
of dispatcher queue can hang due to race with adding the signal message into the queue from
session operation and cleaning the queue by failover. Here is a dump of hang commit operation:
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x000000000241c000 nid=0x2e18 waiting on condition [0x0000000002a9f000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x000000076d9f4c70> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> 	at org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2343)
> 	at org.apache.qpid.client.AMQSession.rollback(AMQSession.java:1984)
> 	- locked <0x000000076d67e5f8> (a java.lang.Object)
> 	at org.apache.qpid.client.AMQSession.commit(AMQSession.java:922)
> 	at org.apache.qpid.test.Test.main(Test.java:40)
> {noformat}
> The defect was introduced as part of changes committed against QPID-3521. I do not see
any sensible work around for the issue.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message