[
https://issues.apache.org/jira/browse/AMQ-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125007#comment-13125007
]
Martin Serrano commented on AMQ-3535:
-------------------------------------
I will attach a better patch. What you say makes sense, and I will test only
using MessageAck.INDIVIDUAL_ACK_TYPE. I have just discovered this and am not
sure how to reproduce in a test case. I found it in a integration test that
has multiple processes. I'll see what I can do. This occurs after a
master/slave failover. Do you want the patch without the test case or would
you rather wait?
> ActiveMQMessageConsumer auto ack of duplicates always sends a standard ack
> --------------------------------------------------------------------------
>
> Key: AMQ-3535
> URL: https://issues.apache.org/jira/browse/AMQ-3535
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.5.0
> Reporter: Martin Serrano
> Priority: Critical
>
> When the ActiveMQMessageConsumer auto acks a duplicate, it always sends a
> standard ack. This occurs even when the session was opened in individual
> acknowledge mode. This results in the acknowledgments usually generating the
> "unmatched ack" message, causing the ack to be dropped. Since this is a
> duplicate, generally things are okay, but the spurious error message is
> troubling and the inflight and dequeue counts will be wrong from then on.
> The following patch fixes the issue:
> {code:java}
> Index: src/org/apache/activemq/ActiveMQMessageConsumer.java
> ===================================================================
> --- src/org/apache/activemq/ActiveMQMessageConsumer.java (revision 46059)
> +++ src/org/apache/activemq/ActiveMQMessageConsumer.java (working copy)
> @@ -1257,7 +1257,8 @@
> if (LOG.isDebugEnabled()) {
> LOG.debug(getConsumerId() + " ignoring (auto
> acking) duplicate: " + md.getMessage());
> }
> - MessageAck ack = new MessageAck(md,
> MessageAck.STANDARD_ACK_TYPE, 1);
> +
> + MessageAck ack = new MessageAck(md, (byte)
> session.acknowledgementMode, 1);
> session.sendAck(ack);
> } else {
> if (LOG.isDebugEnabled()) {
> {code}
> I have also noticed that there are several places in ActiveMQMessageConsumer
> that allow potential creation of acks that do not coincide with the session
> settings. Perhaps ActiveMQSession.sendAck should throw
> IllegalArgumentException if the ack type does not match the session?
--
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
