[
https://issues.apache.org/jira/browse/AMQ-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Serrano updated AMQ-3535:
--------------------------------
Description:
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?
was:
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 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?
> 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
