Red Hat Bugzilla – Bug 754990
qpidd broker ring queue limit depth working differently with --default-queue-limit=0 vs. default
Last modified: 2014-11-09 17:38:20 EST
Description of problem: QPID-3180 issue was fixed in qpid-cpp-0.12, but other smaller was detected: A ring queue behavior is slightly different when broker is ran with parameter --default-queue-limit=0 (which should cause no effect on behavior). Let's assume following case: Create a ring queue (ring/ring-strict) with qpid.max_count=5 Send 10 messages Receive all messages Expect last 5 messages to be received When broker is ran with no --default-queue-limit (i.e. default value), then above scenario works well and client receives last 5 messages. When broker is ran with --default-queue-limit=0 (i.e. no queue size byte limit), then in above scenario client receives last 4 messages only. This seems to be off-by-one problem caused incomplete fix of QPID-3180. This issue was detected on both RHEL6.2 i686 / x86_64. Version-Release number of selected component (if applicable): qpid-cpp-0.12-6.el6 qpid-qmf-0.12-6.el6 How reproducible: 100% Steps to Reproduce: 1. qpidd --no-module-dir 2. python bz441700.py -> check result 3. qpidd --no-module-dir --default-queue-limit=0 4. python bz441700.py -> check result Actual results: Ring queue behavior differs. Expected results: Ring queue behavior should be equivalent in both above mentioned cases. Additional info: [root@dhcp-27-50 QPID3180]# killall qpidd qpidd: no process killed [root@dhcp-27-50 QPID3180]# qpidd --no-module-dir 2011-11-18 13:08:29 notice Listening on TCP port 5672 2011-11-18 13:08:29 notice Broker running ^Z [1]+ Stopped qpidd --no-module-dir [root@dhcp-27-50 QPID3180]# bg [1]+ qpidd --no-module-dir & [root@dhcp-27-50 QPID3180]# python bz441700.py ----> TEST-A - Policy: ring - Ring size: 5 - Using queue name: ringq_testA_ring_5 Sending: ring test A ... message 1/10 Sending: ring test A ... message 2/10 Sending: ring test A ... message 3/10 Sending: ring test A ... message 4/10 Sending: ring test A ... message 5/10 Sending: ring test A ... message 6/10 Sending: ring test A ... message 7/10 Sending: ring test A ... message 8/10 Sending: ring test A ... message 9/10 Sending: ring test A ... message 10/10 Received: ring test A ... message 6/10 Received: ring test A ... message 7/10 Received: ring test A ... message 8/10 Received: ring test A ... message 9/10 Received: ring test A ... message 10/10 Message queue is empty Got the expected number of messages ====> TEST-A - PASS ----> TEST-B - Policy: ring_strict - Ring size: 5 - Using queue name: ringq_testB_ring_strict_5 Sending: ring test B ... message 1/10 Sending: ring test B ... message 2/10 Sending: ring test B ... message 3/10 Sending: ring test B ... message 4/10 Sending: ring test B ... message 5/10 Sending: ring test B ... message 6/10 Sending: ring test B ... message 7/10 Sending: ring test B ... message 8/10 Sending: ring test B ... message 9/10 Sending: ring test B ... message 10/10 Received: ring test B ... message 6/10 Received: ring test B ... message 7/10 Received: ring test B ... message 8/10 Received: ring test B ... message 9/10 Received: ring test B ... message 10/10 Message queue is empty Got the expected number of messages ====> TEST-B - PASS ... SUMMARY: Score: 0 (0 = no errors) Overall result: PASS [root@dhcp-27-50 QPID3180]# killall qpidd 2011-11-18 13:09:27 notice Shut down [root@dhcp-27-50 QPID3180]# qpidd --no-module-dir --default-queue-limit=0 2011-11-18 13:09:27 notice Listening on TCP port 5672 2011-11-18 13:09:27 notice Broker running ^Z[1] Done qpidd --no-module-dir [2]+ Stopped qpidd --no-module-dir --default-queue-limit=0 [root@dhcp-27-50 QPID3180]# bg [2]+ qpidd --no-module-dir --default-queue-limit=0 & [root@dhcp-27-50 QPID3180]# python bz441700.py ----> TEST-A - Policy: ring - Ring size: 5 - Using queue name: ringq_testA_ring_5 Sending: ring test A ... message 1/10 Sending: ring test A ... message 2/10 Sending: ring test A ... message 3/10 Sending: ring test A ... message 4/10 Sending: ring test A ... message 5/10 Sending: ring test A ... message 6/10 Sending: ring test A ... message 7/10 Sending: ring test A ... message 8/10 Sending: ring test A ... message 9/10 Sending: ring test A ... message 10/10 Received: ring test A ... message 7/10 Received: ring test A ... message 8/10 Received: ring test A ... message 9/10 Received: ring test A ... message 10/10 Message queue is empty FAIL: Received too few messages ====> TEST-A - FAIL ----> TEST-B - Policy: ring_strict - Ring size: 5 - Using queue name: ringq_testB_ring_strict_5 Sending: ring test B ... message 1/10 Sending: ring test B ... message 2/10 Sending: ring test B ... message 3/10 Sending: ring test B ... message 4/10 Sending: ring test B ... message 5/10 Sending: ring test B ... message 6/10 Sending: ring test B ... message 7/10 Sending: ring test B ... message 8/10 Sending: ring test B ... message 9/10 Sending: ring test B ... message 10/10 Received: ring test B ... message 7/10 Received: ring test B ... message 8/10 Received: ring test B ... message 9/10 Received: ring test B ... message 10/10 Message queue is empty FAIL: Received too few messages ====> TEST-B - FAIL ... SUMMARY: Score: 2 (0 = no errors) Overall result: FAIL
Created attachment 534397 [details] Testing client (low-level API)
Good catch! Further fix committed upstream as http://svn.apache.org/viewvc?rev=1203835&view=rev.
Issue still pending on qpid-*-0.14*.
This issue is still not fixed in the latest Messaging 2.2 build. Observed on RHEL5.8 and RHEL6.3 both i386 and x86_64. Packages used for testing: qpid-cpp-0.14-18.el6_3 qpid-cpp-0.14-18.el5
Tested on RHEL5.8 and RHEL6.3 (both i386 and x86_64). The ring queue behaviour is now consistent, setting default-queue-limit=0 does not change it. Packages used for testing: RHEL5.8 qpid-cpp-client-0.18-1.el5 qpid-cpp-client-devel-0.18-1.el5 qpid-cpp-client-devel-docs-0.18-1.el5 qpid-cpp-client-rdma-0.18-1.el5 qpid-cpp-client-ssl-0.18-1.el5 qpid-cpp-mrg-debuginfo-0.18-1.el5 qpid-cpp-server-0.18-1.el5 qpid-cpp-server-cluster-0.18-1.el5 qpid-cpp-server-devel-0.18-1.el5 qpid-cpp-server-rdma-0.18-1.el5 qpid-cpp-server-ssl-0.18-1.el5 qpid-cpp-server-store-0.18-1.el5 qpid-cpp-server-xml-0.18-1.el5 RHEL6.3 qpid-cpp-client-0.18-1.el6_3 qpid-cpp-client-devel-0.18-1.el6_3 qpid-cpp-client-devel-docs-0.18-1.el6_3 qpid-cpp-client-rdma-0.18-1.el6_3 qpid-cpp-client-ssl-0.18-1.el6_3 qpid-cpp-debuginfo-0.18-1.el6_3 qpid-cpp-server-0.18-1.el6_3 qpid-cpp-server-cluster-0.18-1.el6_3 qpid-cpp-server-devel-0.18-1.el6_3 qpid-cpp-server-rdma-0.18-1.el6_3 qpid-cpp-server-ssl-0.18-1.el6_3 qpid-cpp-server-store-0.18-1.el6_3 qpid-cpp-server-xml-0.18-1.el6_3 -> 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