Bug 509449
| Summary: | JMS client releases messages in an unpredictable order on recover | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Rajith Attapattu <rattapat+nobody> |
| Component: | qpid-java | Assignee: | Rajith Attapattu <rattapat+nobody> |
| Status: | CLOSED ERRATA | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 1.1.2 | CC: | gsim |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Previously, a JMS client released messages in an unpredictable order when trying to recover. This resulted in messages being re-queued in an unpredictable order even if there was only one consumer. This unpredictability was due to undispatched messages ending up being released in the dispatch thread. This may have happened before or after the messages arrived in the consumers fetch queue. With this update, the messages are now released in the order they arrived in the queue. If a client calls for a recover, messages are not released in the order they arrived in the queue, hence, the next time they are sent to the client, the original ordering is preserved. Please note that this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-14 16:15:59 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: | |||
|
Description
Rajith Attapattu
2009-07-02 20:23:13 UTC
This is fixed in rev 934236 in Qpid trunk. Added two test cases in rev 939410 in Qpid trunk. You could run them by doing, "ant test -Dprofile=cpp -Dtest=RecoverTest" The two specific test cases are, testOderingWithAsyncConsumer testOderingWithSyncConsumer
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause: JMS client releases messages in an unpredictable order on recover.
Consequence: When messages are released on recover, the order of release is unpredictable. This results in messages being requeued in an unpredictable order even if there
is only one consumer. The unpredictability is because messages that have yet to be dispatched end up being released in the dispatch thread and this may sometimes happen before or after the messages arrive in the consumers fetch queue.
Fix: The messages are now released in the order they arrived in the queue.
Result: If client calls recover messages are not released in the order they arrived in the queue, hence the next time it's sent to the client the original ordering is preserved. Please note this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,10 +1 @@
-Cause: JMS client releases messages in an unpredictable order on recover.
+Previously, a JMS client released messages in an unpredictable order when trying to recover. This resulted in messages being requeued in an unpredictable order even if there was only one consumer. The unpredictability was caused by the messages that had yet to be dispatched ended up being released in the dispatch thread. This may have happened before or after the messages arrived in the consumers fetch queue. With this update, the messages are now released in the order they arrived in the queue. If a client calls for a recover, messages are not released in the order they arrived in the queue, hence, the next time they are sent to the client, the original ordering is preserved. Please note that this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.-
-Consequence: When messages are released on recover, the order of release is unpredictable. This results in messages being requeued in an unpredictable order even if there
-is only one consumer. The unpredictability is because messages that have yet to be dispatched end up being released in the dispatch thread and this may sometimes happen before or after the messages arrive in the consumers fetch queue.
-
-
-Fix: The messages are now released in the order they arrived in the queue.
-
-
-Result: If client calls recover messages are not released in the order they arrived in the queue, hence the next time it's sent to the client the original ordering is preserved. Please note this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1 +1 @@
-Previously, a JMS client released messages in an unpredictable order when trying to recover. This resulted in messages being requeued in an unpredictable order even if there was only one consumer. The unpredictability was caused by the messages that had yet to be dispatched ended up being released in the dispatch thread. This may have happened before or after the messages arrived in the consumers fetch queue. With this update, the messages are now released in the order they arrived in the queue. If a client calls for a recover, messages are not released in the order they arrived in the queue, hence, the next time they are sent to the client, the original ordering is preserved. Please note that this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.+Previously, a JMS client released messages in an unpredictable order when trying to recover. This resulted in messages being re-queued in an unpredictable order even if there was only one consumer. This unpredictability was due to undispatched messages ending up being released in the dispatch thread. This may have happened before or after the messages arrived in the consumers fetch queue. With this update, the messages are now released in the order they arrived in the queue. If a client calls for a recover, messages are not released in the order they arrived in the queue, hence, the next time they are sent to the client, the original ordering is preserved. Please note that this is only valid if there is only one consumer present on the queue. If there are multiple consumers the ordering cannot be guaranteed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html |