| Summary: | release does not reset active cursors on priority queues | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Gordon Sim <gsim> | ||||
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Zdenek Kraus <zkraus> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | Development | CC: | esammons, gsim, iboverma, jross, zkraus | ||||
| Target Milestone: | 3.0 | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | qpid-cpp-0.22-12 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-01-21 12:56:32 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Fixed upstream: https://svn.apache.org/r1515793. Note this would be a regression from previous MRG releases. Backported to 0.22-mrg branch here: http://git.app.eng.bos.redhat.com/?p=rh-qpid.git;a=shortlog;h=refs/heads/0.22-mrg-BZ999499 Tested on RHEL 6 i686 && x86_64 with following packaged: qpid-cpp-client-0.22-38 qpid-cpp-client-devel-0.22-38 qpid-cpp-client-devel-docs-0.22-38 qpid-cpp-client-rdma-0.22-38 qpid-cpp-debuginfo-0.22-38 qpid-cpp-server-0.22-38 qpid-cpp-server-devel-0.22-38 qpid-cpp-server-ha-0.22-38 qpid-cpp-server-linearstore-0.22-38 qpid-cpp-server-rdma-0.22-38 qpid-cpp-server-xml-0.22-38 works as expected. |
Created attachment 788840 [details] a simple reproducer Description of problem: Version-Release number of selected component (if applicable): Since qpid-0.20 How reproducible: 100% Steps to Reproduce: 1. put a message in a priority queue 2. create a receiver from that queue 3. fetch the message then release 4. try to fetch it again Actual results: Subsequent fetch() attempts on released message fail. Expected results: Subsequent fetch() attempts on released message return the released message. Additional info: Using attached reproducer, the bug is that the test stops after fetching the message once. When fixed it continues in a loop refetching the same released message. Upstream fix also includes a simple (similar) test case.