[
https://issues.apache.org/jira/browse/AMQ-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125003#comment-13125003
]
Gary Tully commented on AMQ-3535:
---------------------------------
I think that ack should always be an individual ack, not one that matches all
preceding messages. So MessageAck.INDIVIDUAL_ACK_TYPE. Can you validate that?
Any chance that you have a test case?
note: when you provide a patch, you need to attach the patch file and tick the
check box to license grant on the file upload form. Otherwise we can't commit
it.
> 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
