[
https://issues.apache.org/jira/browse/AMQ-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-5279:
---------------------------------
Fix Version/s: 5.10.1
> 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.10.1, 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.3.4#6332)
