[
https://issues.apache.org/jira/browse/AMQ-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated AMQ-3781:
--------------------------------
Attachment: JmsRedeliveryDeadSessionTest.java
> Redelivery counter is not maintained across Session.close()
> -----------------------------------------------------------
>
> Key: AMQ-3781
> URL: https://issues.apache.org/jira/browse/AMQ-3781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
> Affects Versions: 5.5.1
> Reporter: Raul Kripalani
> Attachments: JmsRedeliveryDeadSessionTest.java
>
>
> If a message enters a redelivery cycle of e.g. 10 maximum redelivery
> attempts, and the session is closed halfway through it (e.g. after consuming
> attempt 5), the next time the session is established and the message is
> consumed, it will have RedeliveryCount=2 rather than 6. As a result, the
> message will end up being materially redelivered 14 times, thus exceeding the
> configured maximum.
> With the current set up, where it's the consumer-side AMQ logic who is in
> charge of tallying up the redelivery attempts and sending back the Poison
> ACK, it seems that there is a missing command when the session is being
> closed *gracefully* from consumer -> broker informing of the redelivery
> counters of messages in redelivery process.
> If the session was being closed suddenly, I suppose to some extent it would
> be okay to miscount the redeliveries, since there was no chance to execute a
> closure process for the client to update the broker accordingly.
> This is also a case for AMQ to support broker-controlled redeliveries (see
> AMQ-3597).
> Unit test reproducing the problem is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
