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-cpp | Assignee: | Ted Ross <tross> |
| Status: | CLOSED ERRATA | QA Contact: | Petr Matousek <pematous> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 1.3 | CC: | iboverma, jross, lzhaldyb, mcressma, pematous, tross |
| Target Milestone: | 2.3 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 698367, 803771 | ||
|
Description
Andy Goldstein
2011-09-12 21:19:48 UTC
Reproducer:
Run the following Python script against a broker:
======== start ========
from qpid.messaging import Connection
conn=Connection("localhost")
conn.open()
sess = conn.session()
rx = sess.receiver("amq.direct/key;{link:{x-declare:{alternate-exchange:'amq.fanout'}}}")
tx = sess.sender("amq.direct/key")
tx.send("TEST")
tx.send("TEST")
tx.send("TEST")
tx.send("TEST")
tx.send("TEST")
m = rx.fetch()
m = rx.fetch()
m = rx.fetch()
sess.close()
conn.close()
======== 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.
Fixed upstream in Qpid SVN revision 1239728. This update will be picked up in Qpid 0.16 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'}}}") 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. (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 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. http://rhn.redhat.com/errata/RHSA-2013-0561.html |