Bug 737685

Summary: Acquired messages are not sent to alternate exchange when queue is deleted and receiver's session closed
Product: Red Hat Enterprise MRG Reporter: Andy Goldstein <agoldste>
Component: qpid-cppAssignee: Ted Ross <tross>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: high Docs Contact:
Priority: high    
Version: 1.3CC: iboverma, jross, lzhaldyb, mcressma, pematous, tross
Target Milestone: 2.3   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: qpid-cpp-0.18-1 Doc Type: Bug Fix
Doc Text:
Cause: A defect in the qpid broker caused messages that were delivered and acquired by a consumer but not yet acknowledged to not be delivered to the alternate exchange when the queue was deleted. Consequence: Unacknowledged messages could be lost if they were expected to be delivered to the alternate exchange. Fix: The broker was fixed to address this problem. Result: All unacknowledged messages in a queue are now delivered to the alternate exchange regardless of whether or not they have been acquired by a consumer.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-06 18:54:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 698367, 803771    

Description Andy Goldstein 2011-09-12 21:19:48 UTC
See https://issues.apache.org/jira/browse/QPID-3481

Comment 1 Ted Ross 2012-02-01 20:18:24 UTC

Run the following Python script against a broker:

======== start ========
from qpid.messaging import Connection
sess = conn.session()
rx = sess.receiver("amq.direct/key;{link:{x-declare:{alternate-exchange:'amq.fanout'}}}")
tx = sess.sender("amq.direct/key")
m = rx.fetch()
m = rx.fetch()
m = rx.fetch()
======== end ========

Once this is done, use "qpid-stat -e" to look at the "msgIn" counter on the amq.fanout exchange.

The correct value is 5;  with the bug, the value will be 2 because the three acquired-but-not-acknowledged messages will not be routed to the alternate exchange.

Comment 2 Ted Ross 2012-02-02 17:16:37 UTC
Fixed upstream in Qpid SVN revision 1239728.

This update will be picked up in Qpid 0.16

Comment 4 Petr Matousek 2012-10-22 13:49:09 UTC
From my point of view, the behaviour reported in comment 1 is correct. 
The reliability for subscription queues (receiver for exchange) is unreliable by default. The three fetched messages are implicitly accepted, thus only the two remaining messages shall be routed to the alternate exchange.

Ted, I assume you forgot to provide 'reliability:at-least-once' in the receiver definition of the reproducer, am I correct?

The current implementation meets my expectation:
When the reliability option is not provided (unreliable by default) only two messages are routed to the alternate exchange.
When the subscription queue is set to be reliable all 5 messages are routed to the alternate exchange. (this was actually a bug on previous packages, the 3 acquired-but-not-acknowledged messages were not routed to the alt.exchange)

So the issue seems to be fixed, assuming the following change in the reproducer provided in comment 1:
- rx = sess.receiver("amq.direct/key;{link:{x-declare:{alternate-exchange:'amq.fanout'}}}")
+ rx = sess.receiver("amq.direct/key;{link:{reliability:at-least-once,x-declare:{alternate-exchange:'amq.fanout'}}}")

Comment 5 Petr Matousek 2012-10-27 13:03:08 UTC
This issue has been fixed.

Verified on rhel5.8 and rhel6.3 (x86_64, i386)

packages used for testing:

-> can be moved to VERIFIED after Ted confirms my assumptions made in comment 4.

Comment 6 Ted Ross 2012-10-30 17:44:43 UTC
(In reply to comment #5)
> This issue has been fixed.
> Verified on rhel5.8 and rhel6.3 (x86_64, i386)
> packages used for testing:
> qpid-cpp-0.18-2
> -> can be moved to VERIFIED after Ted confirms my assumptions made in
> comment 4.

Confirmed, please move to VERIFIED

Comment 8 errata-xmlrpc 2013-03-06 18:54:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.