activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (Commented) (JIRA)" <>
Subject [jira] [Commented] (AMQ-3535) ActiveMQMessageConsumer auto ack of duplicates always sends a standard ack
Date Tue, 11 Oct 2011 13:27:12 GMT


Gary Tully commented on AMQ-3535:

A patch with a junit test would be ideal :-) Thanks for the contribution, much appreciated.

Have a peek at org.apache.activemq.transport.failover.FailoverTransactionTest for some inspiration.
In any event I think you found a bug, but I am interested to understand how the inflight and
dequeue counts get out of sync.
> ActiveMQMessageConsumer auto ack of duplicates always sends a standard ack
> --------------------------------------------------------------------------
>                 Key: AMQ-3535
>                 URL:
>             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.
> 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:!default.jspa
For more information on JIRA, see:


View raw message