You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2015/02/14 21:12:11 UTC
[jira] [Updated] (AMQCPP-552) Honor RedeliveryPolicy for message
redelivered by the Broker.
[ https://issues.apache.org/jira/browse/AMQCPP-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish updated AMQCPP-552:
--------------------------------
Fix Version/s: (was: 3.8.4)
3.8.5
> Honor RedeliveryPolicy for message redelivered by the Broker.
> -------------------------------------------------------------
>
> Key: AMQCPP-552
> URL: https://issues.apache.org/jira/browse/AMQCPP-552
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
> Affects Versions: 3.8.0, 3.8.1, 3.8.2, 3.8.3
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Fix For: 3.8.5, 3.9.0
>
>
> Port changes from AMQ-5146 which respects the redelivery maximum for messages that are dispatched to a consumer from the Broker.
> {noformat}
> A consumer with a transacted session that dies after receive or in onMessage (due to some of the message content for example), but before the a transaction can complete will continue to receive the message.
> The connection will die, the transaction will rollback, the broker will increment the redeliveryCounter and redispatch the message.
> However the redeliveryPolicy, which is only checked on rollback (client side) will never kick in.
> the result is infinite redelivery with an ever incrementing redeliveryCounter.
> It is a reasonable expectation that this message would eventually find its way into the dlq.
> The broker redelivery plugin does not help because it is triggered by the client side poison ack.
> Either the broker redelivery plugin can get involved before dispatch, or a client can do a predispatch check.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)