You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2014/07/17 18:09:04 UTC

[jira] [Resolved] (AMQ-5279) failover redelivery to alternative consumers with pending transaction causes rollback *and* dlq processing

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

Gary Tully resolved AMQ-5279.
-----------------------------

    Resolution: Fixed

fix in http://git-wip-us.apache.org/repos/asf/activemq/commit/c34851fd

> failover redelivery to alternative consumers with pending transaction  causes rollback *and* dlq processing
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-5279
>                 URL: https://issues.apache.org/jira/browse/AMQ-5279
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.10.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>              Labels: dlq, failover, redelivery, transaction
>             Fix For: 5.11.0
>
>
> failover isolates the application client from transport failures. For a single consumer, if there is a pending transaction and an ack is lost the transaction can still commit after failover if the messages is redispatched. If it is not redispatched, then the transaction will rollback.
> With multiple consumers it is possible that an alternative consumer will get redelivery. If the alternative consumer is on a different connection the duplicate dispatch (tracked by a connection) is not identified, redelivery ensues and the pending transaction rolls back.
> If the consumer is on the same connection, the redelivery is treated as a duplicate, the message gets a poison ack and the pending transaction rolls back. This is a double whammy and results in a delivery to the DLQ in error.
> The redelivery should be routed to the alternative consumer as if it were on a different connection so that the message can be consumed.
> We should DLQ only when the redispatch is not pending on any consumer.



--
This message was sent by Atlassian JIRA
(v6.2#6252)