Bug 754990 - qpidd broker ring queue limit depth working differently with --default-queue-limit=0 vs. default
Summary: qpidd broker ring queue limit depth working differently with --default-queue-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: Development
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: 2.3
: ---
Assignee: Gordon Sim
QA Contact: Leonid Zhaldybin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-18 13:53 UTC by Frantisek Reznicek
Modified: 2014-11-09 22:38 UTC (History)
6 users (show)

Fixed In Version: qpid-cpp-0.18-1
Doc Type: Bug Fix
Doc Text:
Cause: The ring policy enforcement logic did not take account of the case where no maximum size was specified, only a maximum count. Consequence: A maximum size of 0 (i.e. unspecified) would result in a message being needless removed. Fix: The logic was updated to correctly handle the case where the size is not limited but the count is. Result: The policy is correctly enforced (and the behaviour is the same regardless of the default-queue-limit set).
Clone Of:
Environment:
Last Closed: 2013-03-06 18:54:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Testing client (low-level API) (9.63 KB, application/x-python)
2011-11-18 13:54 UTC, Frantisek Reznicek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA QPID-3180 0 None None None Never
Red Hat Product Errata RHSA-2013:0561 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging 2.3 security update 2013-03-06 23:48:13 UTC

Description Frantisek Reznicek 2011-11-18 13:53:17 UTC
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

Comment 1 Frantisek Reznicek 2011-11-18 13:54:45 UTC
Created attachment 534397 [details]
Testing client (low-level API)

Comment 2 Gordon Sim 2011-11-18 21:06:57 UTC
Good catch! Further fix committed upstream as http://svn.apache.org/viewvc?rev=1203835&view=rev.

Comment 3 Frantisek Reznicek 2012-02-14 15:23:25 UTC
Issue still pending on qpid-*-0.14*.

Comment 4 Leonid Zhaldybin 2012-07-20 06:55:26 UTC
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

Comment 7 Leonid Zhaldybin 2012-10-09 12:00:08 UTC
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

Comment 9 errata-xmlrpc 2013-03-06 18:54:15 UTC
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


Note You need to log in before you can comment on or make changes to this bug.