Bug 733704 - '--limit-policy ring-strinct' implements same policy as 'ring'
Summary: '--limit-policy ring-strinct' implements same policy as 'ring'
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 2.1
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-26 14:41 UTC by Zdenek Kraus
Modified: 2013-02-24 15:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-26 15:14:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Test case for --limit-policy ring-strict (3.20 KB, application/x-sh)
2011-08-26 14:41 UTC, Zdenek Kraus
no flags Details

Description Zdenek Kraus 2011-08-26 14:41:50 UTC
Created attachment 520102 [details]
Test case for --limit-policy ring-strict

Description of problem:
When limiting queue with ring-strict broker should not accept and replace older messages in Queue. It should reply an exception to sender and reject exceeding messages.

But it implements 'ring' policy, and accept newer messages and replacing older.


Version-Release number of selected component (if applicable):
qpid-cpp-server-0.10-8.el5
qpid-cpp-server-devel-0.10-8.el5
python-qpid-0.10-1.el5

How reproducible:
100%

Steps to Reproduce:
1. start default broker (could be --auth=no), eg:
$ qpidd --auth=no --data-dir /tmp/ring_strict_test &
2. create limited queue, eg:
$ qpid-config add queue ring_strict_test --limit-policy ring-strict --max-queue-count 5
3. send exceeding amount of messages, eg:
$ cd /usr/share/doc/python-qpid-0.10/examples/api
$ ./spout -c 10 ring_strict_test
4. receive Queued messages
$ ./drain ring_strict_test
5. observe that newer messages has been received

** or use attached reproducer (I will attach it)

Actual results:
$ ./spout -c 10 ring_strict_test
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:0'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:1'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:2'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:3'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:4'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:5'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:6'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:7'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:8'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:9'})

$ ./drain ring_strict_test
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:5'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:6'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:7'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:8'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:9'})


Expected results:
$ ./spout -c 10 ring_strict_test
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:0'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:1'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:2'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:3'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:4'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:5'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:6'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:7'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:8'})
Message(properties={'spout-id': 'd57ceba2-316e-4543-8fe4-e876a3d65473:9'})

$ ./drain ring_strict_test
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:0'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:1'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:2'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:3'})
Message(properties={'x-amqp-0-10.routing-key': u'ring_strict_test', u'spout-id': u'd57ceba2-316e-4543-8fe4-e876a3d65473:4'})

Additional info:

Comment 1 Gordon Sim 2011-08-26 15:06:53 UTC
That is not how ring-strict works. The only difference as compared to the standard ring policy, is that messages will not be overwritten if they have been given to a consumer who has not yet acknowledged them. In your example that is not the case, so it will behave exactly as a ring queue.

To see the difference you need a client that will not immediately acknowledge messages. E.g. using qpid-receive from qpid svn[1] run:

    qpid-receive --address ring_strict_test -f

before starting spout above and you should see spout fail with an exception due to being unable to replace messages.

[1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/tests/qpid-receive.cpp

Comment 2 Zdenek Kraus 2011-08-26 15:14:52 UTC
Ok, that is my misunderstanding of documentation. Thank you for clarification.


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