| Summary: | Ensure that replaced LVQ messages are deleted from store | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Pavel Moravec <pmoravec> |
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> |
| Status: | CLOSED ERRATA | QA Contact: | Leonid Zhaldybin <lzhaldyb> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 2.3 | CC: | esammons, iboverma, jross, lzhaldyb, mcressma, sauchter |
| Target Milestone: | 2.4.4 | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qpid-cpp-0.18-19 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: The logic used to determine whether a message needed to be removed from the store was incorrect. It did not account for the case where the message had already been removed from the in-memory queue, as is the case when an LVQ message is replaced.
Consequence: Durable LVQ messages did not get removed from the store and the journal grew until it reached the limit.
Fix: The logic was corrected to account for the case where the message had already been removed from the in-memory queue.
Result: Durable LVQ messages are removed from the store when replaced.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-02-11 08:29:04 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: | |
|
Description
Pavel Moravec
2013-12-02 12:34:35 UTC
FYI the bug is _not_ in store module, but in MessageMap <-> Queue call flow for LVQ queue. See below what happens for LVQ, when enqueueing a new message with an LVQ key of some already enqueued message (ideally, the original message should be removed from MessageMap and from store): 1) Queue::deliver calls Queue::push that: a) calls MessageMap::push that calls MessageMap::replace and _removes_ original message from the map (and adds there the new one) b) calls Queue::dequeue (as already stored message needs to be dequeued) 2) Queue::dequeue calls "deleted = messages->deleted(msg);" with return value false - as MessageMap already replaced the original message 3) Hence the method evaluates test: if ((msg.payload->isPersistent() || msg.payload->checkContentReleasable()) && store && deleted) to false and the original message is _not_ removed from the store. Crucial question: why value of "deleted" could determine removing the message from store? Is there some use case when messages->deleted(msg) is false and we should keep the message in store? (is it really flow-to-disk feature? if so, can't we add a nasty fix: deleted = deleted && policy_is_FTD ?) Pavel, thanks for helping me direct this one to the right place. (In reply to Pavel Moravec from comment #2) > Crucial question: why value of "deleted" could determine removing the > message from store? Is there some use case when messages->deleted(msg) is > false and we should keep the message in store? The test is required to determine whether the message is still on the queue, e.g. when a message on an LVQ is acked after it has been replaced. The QueueuPolicy::isEnqueued() only protects the ring-queue case, not LVQ. As you point out, in the case that messages are dequeued after being replaced by a new message in push(), this check is not needed and will give the wrong result since the message has already been removed from messages. I've pushed a branch with a proposed fix: http://git.app.eng.bos.redhat.com/rh-qpid.git/log/?h=0.18-mrg_BZ1036650 Tested on RHEL5.10 and RHEL6.5 (both i386 and x86_64). This issue has been fixed. Packages used for testing: RHEL5.10 python-qpid-0.18-8.el5_10 python-qpid-qmf-0.18-20.el5_10 qpid-cpp-client-0.18-20.el5_10 qpid-cpp-client-devel-0.18-20.el5_10 qpid-cpp-client-devel-docs-0.18-20.el5_10 qpid-cpp-client-rdma-0.18-20.el5_10 qpid-cpp-client-ssl-0.18-20.el5_10 qpid-cpp-server-0.18-20.el5_10 qpid-cpp-server-cluster-0.18-20.el5_10 qpid-cpp-server-devel-0.18-20.el5_10 qpid-cpp-server-ha-0.18-20.el5_10 qpid-cpp-server-rdma-0.18-20.el5_10 qpid-cpp-server-ssl-0.18-20.el5_10 qpid-cpp-server-store-0.18-20.el5_10 qpid-cpp-server-xml-0.18-20.el5_10 qpid-java-client-0.18-8.el5_9 qpid-java-common-0.18-8.el5_9 qpid-java-example-0.18-8.el5_9 qpid-jca-0.18-8.el5 qpid-jca-xarecovery-0.18-8.el5 qpid-jca-zip-0.18-8.el5 qpid-qmf-0.18-20.el5_10 qpid-qmf-devel-0.18-20.el5_10 qpid-tests-0.18-2.el5 qpid-tools-0.18-10.el5_9 rh-qpid-cpp-tests-0.18-20.el5_10 ruby-qpid-qmf-0.18-20.el5_10 RHEL6.5 python-qpid-0.18-8.el6 python-qpid-qmf-0.18-20.el6 qpid-cpp-client-0.18-20.el6 qpid-cpp-client-devel-0.18-20.el6 qpid-cpp-client-devel-docs-0.18-20.el6 qpid-cpp-client-rdma-0.18-20.el6 qpid-cpp-client-ssl-0.18-20.el6 qpid-cpp-server-0.18-20.el6 qpid-cpp-server-cluster-0.18-20.el6 qpid-cpp-server-devel-0.18-20.el6 qpid-cpp-server-ha-0.18-20.el6 qpid-cpp-server-rdma-0.18-20.el6 qpid-cpp-server-ssl-0.18-20.el6 qpid-cpp-server-store-0.18-20.el6 qpid-cpp-server-xml-0.18-20.el6 qpid-java-client-0.18-8.el6_4 qpid-java-common-0.18-8.el6_4 qpid-java-example-0.18-8.el6_4 qpid-jca-0.18-8.el6 qpid-jca-xarecovery-0.18-8.el6 qpid-jca-zip-0.18-8.el6 qpid-qmf-0.18-20.el6 qpid-qmf-devel-0.18-20.el6 qpid-tests-0.18-2.el6 qpid-tools-0.18-10.el6_4 rh-qpid-cpp-tests-0.18-20.el6 ruby-qpid-qmf-0.18-20.el6 -> 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/RHBA-2014-0130.html |