Bug 652463
| Summary: | Acknowledged messages are not confirmed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Ted Ross <tross> | ||||||
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | ppecka <ppecka> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | urgent | ||||||||
| Version: | 1.3 | CC: | freznice, jneedle | ||||||
| Target Milestone: | 1.3.0.1 | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: |
On the C++ Messaging API, messages that were received and acknowledged through the Session::acknowledge() function were never confirmed. As a result, the set of unconfirmed sequences (in client/amqp0_10/AcceptTracker::State) grew unbounded consuming approximately 140 bytes of memory per call of the Session::acknowledge() function. With this update, memory usage of the receiving process is stable.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 653471 (view as bug list) | Environment: | |||||||
| Last Closed: | 2010-11-30 17:50:24 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: | 653471 | ||||||||
| Attachments: |
|
||||||||
Per Gordon:
If you add two more calls immediately after the session.acknowledge(), the problem is resolved:
session.acknowledge();
session.sync(false);
session.getUnsettledAcks();
Since this is arguably a bug and instructing developers to use this pattern is a bit onerous, we should consider building the last two lines into acknowledge and supplying the fix in an errata.
Created attachment 459885 [details]
Proposed fix
Comment on attachment 459885 [details]
Proposed fix
impl->acknowledge(_sync); sync(false); is a little redundant when sync is true.
This patch is certainly ok. However stylistically I'd prefer a minor modification, keeping the same solution however.
Created attachment 460037 [details]
alternative fix
This follows the same approach as the previous patch. However it ties the cleaning up of accept records to the sync on the session, and then ensures that there is always a sync (blocking or otherwise) as part of an acknowledgement.
This fix is in qpid-cpp-mrg-0.7.946106-21 This fix was built and tagged into devel by request of QE (tosky). Awaiting qa_ack before tagging to candidate and including in the errata. VERIFIED RHEL 5.5 / 4.8 - i386 / x86_64 #rpm -qa | grep qpid | sort -u python-qpid-0.7.946106-14.el5 qpid-cpp-client-0.7.946106-21.el5 qpid-cpp-client-devel-0.7.946106-21.el5 qpid-cpp-client-devel-docs-0.7.946106-21.el5 qpid-cpp-client-ssl-0.7.946106-21.el5 qpid-cpp-mrg-debuginfo-0.7.946106-20.el5 qpid-cpp-server-0.7.946106-21.el5 qpid-cpp-server-cluster-0.7.946106-21.el5 qpid-cpp-server-devel-0.7.946106-21.el5 qpid-cpp-server-ssl-0.7.946106-21.el5 qpid-cpp-server-store-0.7.946106-21.el5 qpid-cpp-server-xml-0.7.946106-21.el5 qpid-java-client-0.7.946106-12.el5 qpid-java-common-0.7.946106-12.el5 qpid-java-example-0.7.946106-12.el5 qpid-tools-0.7.946106-11.el5 --> VERIFIED 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-0921.html
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:
On the C++ Messaging API, messages that were received and acknowledged through the Session::acknowledge() function were never confirmed. As a result, the set of unconfirmed sequences (in client/amqp0_10/AcceptTracker::State) grew unbounded consuming approximately 140 bytes of memory per call of the Session::acknowledge() function. With this update, memory usage of the receiving process is stable.
|
Description of problem: On the C++ Messaging API, receive path, messages that are received and acknowledged via Session::acknowledge() are never confirmed. As a result, the set of unconfirmed sequences (in client/amqp0_10/AcceptTracker::State) grows unbounded. Version-Release number of selected component (if applicable): MRG-M 1.3 How reproducible: 100% Steps to Reproduce: Modify the example "map_receiver" to run this test by simply adding the following code immediately after the creation of the receiver: receiver.setCapacity(200); int count(0); while (true) { Message msg; msg = receiver.fetch(); count++; session.acknowledge(); if (count % 10000 == 0) std::cout << count << std::endl; } Then use "spout" to create the stimulus: $ cpp/examples/messaging/spout message_queue -c 100000 Monitor the memory usage of map_receiver during the test. You may wish to repeat the run of spout multiple times. Actual results: The map_receiver process grows by approximately 140 bytes per call to session.acknowledge(), which in this case is per-message. Expected results: Stable memory usage by the receiving process. Additional info: