Bug 647861
| Summary: | Incorrect handling of datatypes for numeric queue constraints | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Jonathan Robie <jonathan.robie> | |
| Component: | qpid-cpp | Assignee: | Jonathan Robie <jonathan.robie> | |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Reznicek <freznice> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | Development | CC: | esammons, freznice, gsim, iboverma, jneedle, mkudlej, tross | |
| Target Milestone: | 1.3.0.1 | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
When receiving arguments for queue creation, the broker did not interpret strings as numbers for numeric quantities even if the string represented a number. As a result, sending numbers as string values in queue-create arguments caused the values to not take affect in the broker. With this update, the broker now properly interprets numeric values even if they are encoded as strings.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 652087 (view as bug list) | Environment: | ||
| Last Closed: | 2010-11-30 17:50:52 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: | 652087 | |||
|
Description
Jonathan Robie
2010-10-29 17:58:36 UTC
This bug fixes a broker bug. Bug 647860 covers a related C++ client bug that triggered the broker bug. When the broker receives values for max_count or max_size that have invalid values, or are specified using strings rather than numeric types, it was accepting the request, but using the default values. For instance, if the client set max_count or max_size to "3", the string value was ignored and the default value was used instead. The default was also used if the client set max_count or max_size to -1, 3.14159, etc. The following tests, which this patch adds to the unit tests, illustrate the bug: def test_declare_capacity_valid(self): session = self.session try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = 0 session.queue_declare(queue="queue_capacity1", exclusive=True, arguments=queue_options) except SessionException, e: self.fail("Should accept queue create request with name=queue_capacity1, qpid.max_count=0 and qpid.max_size=0") try: queue_options = {} queue_options["qpid.max_count"] = 3 queue_options["qpid.max_size"] = 0 session.queue_declare(queue="queue_capacity2", exclusive=True, arguments=queue_options) except SessionException, e: self.fail("Should accept queue create request with name=queue_capacity2, qpid.max_count=3 and qpid.max_size=0") try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = 300 session.queue_declare(queue="queue_capacity3", exclusive=True, arguments=queue_options) except SessionException, e: self.fail("Should accept queue create request with name=queue_capacity3, qpid.max_count=0 and qpid.max_size=300") try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = "3" session.queue_declare(queue="queue_capacity6", exclusive=True, arguments=queue_options) except SessionException, e: self.fail("Should allow queue create request with qpid.max_size='3'") def test_declare_capacity_invalid(self): session = self.session try: queue_options = {} queue_options["qpid.max_count"] = -1 queue_options["qpid.max_size"] = 0 session.queue_declare(queue="queue_capacity4", exclusive=True, arguments=queue_options) self.fail("Should reject queue create request with name=queue_capacity4, qpid.max_count=-1 and qpid.max_size=0") except SessionException, e: pass try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = -1 session.queue_declare(queue="queue_capacity5", exclusive=True, arguments=queue_options) self.fail("Should reject queue create request with name=queue_capacity5, qpid.max_count=0 and qpid.max_size=-1") except SessionException, e: pass try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = "flummery" session.queue_declare(queue="queue_capacity7", exclusive=True, arguments=queue_options) self.fail("Should deny queue create request with name=queue_capacity7, qpid.max_count=0 and qpid.max_size='flummery'") except SessionException, e: pass try: queue_options = {} queue_options["qpid.max_count"] = 0 queue_options["qpid.max_size"] = 3.14159 session.queue_declare(queue="queue_capacity8", exclusive=True, arguments=queue_options) self.fail("Should deny queue create request with name=queue_capacity4, qpid.max_count=0 and qpid.max_size=3.14159"); except SessionException, e: pass Cherry-picked into: mrg_1.3.x 0d91ab55ae29f197af58ad68e23d07d852370615
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:
Cause: The broker, when receiving arguments for queue creation does not interpret strings as numbers for numeric quantities, even if the string represents a number.
Consequence: Sending numbers as string values in queue-create arguments causes the values to not take affect in the broker.
Fix: The broker has been updated to properly interpret numeric values even if they are encoded as strings.
Result: The broker is much more tolerant of variances in the way arguments are encoded by client libraries.
I've installed new packages:
qpid-tools-0.7.946106-11.el5
qpid-cpp-server-store-0.7.946106-19.el5
python-qpid-0.7.946106-14.el5
qpid-cpp-server-0.7.946106-19.el5
qpid-java-client-0.7.946106-11.el5
qpid-cpp-client-0.7.946106-19.el5
qpid-java-common-0.7.946106-11.el5
qpid-cpp-client-ssl-0.7.946106-19.el5
qpid-cpp-client-devel-docs-0.7.946106-19.el5
qpid-cpp-server-ssl-0.7.946106-19.el5
qpid-java-example-0.7.946106-11.el5
qpid-cpp-server-devel-0.7.946106-19.el5
qpid-cpp-client-devel-0.7.946106-19.el5
qpid-cpp-server-xml-0.7.946106-19.el5
qpid-cpp-server-cluster-0.7.946106-19.el5
python-qmf-0.7.946106-13.el5
qmf-devel-0.7.946106-19.el5
qmf-0.7.946106-19.el5
and try to run testcases above. I've used simple python client to create exchanges with specific properties. There was no exception and I can see exchanges with wrong properties in qpid-tool output so it doesn't use default value and doesn't raise any exception. I've tried testcases with prearranged queues and without prearranged queues with same result.
qpid-tool output:
qpid: show 132
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 132
==================================================================
vhostRef 160
name test1
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': 0L, u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 133
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 133
==================================================================
vhostRef 160
name test2
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': 0L, u'qpid.max_count': 3L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 134
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 134
====================================================================
vhostRef 160
name test3
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': 300L, u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 135
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 135
====================================================================
vhostRef 160
name test4
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': u'3', u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 136
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 136
===================================================================
vhostRef 160
name test5
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': 0L, u'qpid.max_count': -1L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 137
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 137
===================================================================
vhostRef 160
name test6
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': -1L, u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 138
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 138
===========================================================================
vhostRef 160
name test7
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': u'flummery', u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
qpid: show 139
Object of type: org.apache.qpid.broker:exchange(c9bb43df-44ac-63d5-cc1c-6a032025c97d)
Attribute 139
==================================================================================
vhostRef 160
name test8
type direct
durable False
autoDelete False
altExchange 161
arguments {u'qpid.max_size': 3.1415899999999999, u'qpid.max_count': 0L}
producerCount 0
producerCountHigh 0
producerCountLow 0
bindingCount 0
bindingCountHigh 0
bindingCountLow 0
msgReceives 0
msgDrops 0
msgRoutes 0
byteReceives 0
byteDrops 0
byteRoutes 0
Am I doing anything wrong? -->ASSIGNED
The qpid.max_size and qpid.max_count arguments relate to queues not exchanges. The test I would suggest is to use the *python* version of the spout example and run:
"my-queue; {create: always, node: {x-declare: {arguments:{'qpid.max_count':'5'}}}}" --count 10
Before the fix this should succeed without error, resulting in a queue with 10 messages on it. With the fix, the policy should limit the queue size to 5 and spout should fail with qpid.messaging.exceptions.TargetCapacityExceeded: resource-limit-exceeded: Policy exceeded on my-queue.
The defect was retested with joined reproducer from comment 5 and 6 with following results: Issues: a] Queue with queue arguments can be created w/o problem {u'qpid.max_size': 3.1400000000000001, u'qpid.max_count': 0L} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> session = connection.session(str(uuid4())); >>> session.queue_declare(queue="queue_capacityb", exclusive=True, arguments={'qpid.max_count' : '5', 'qpid.max_size': 3.14}); >>> session = connection.session(str(uuid4())); >>> session.queue_declare(queue="queue_capacityc", exclusive=True, arguments={'qpid.max_count' : 7, 'qpid.max_size': '3.14'}); >>> session = connection.session(str(uuid4())); >>> session.queue_declare(queue="queue_capacityd", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': 3.14}); >>> qpid: show 175 Object of type: org.apache.qpid.broker:queue(3a30c319-5ef2-f211-ba1f-4900d5f75435) Attribute 175 ====================================================================================== vhostRef 190 name queue_capacityd durable False autoDelete False exclusive True arguments {u'qpid.max_size': 3.1400000000000001, u'qpid.max_count': 0L} altExchange 192 msgTotalEnqueues 0 msgTotalDequeues 0 msgTxnEnqueues 0 msgTxnDequeues 0 msgPersistEnqueues 0 msgPersistDequeues 0 msgDepth 0 byteDepth 0 byteTotalEnqueues 0 byteTotalDequeues 0 byteTxnEnqueues 0 byteTxnDequeues 0 bytePersistEnqueues 0 bytePersistDequeues 0 consumerCount 0 consumerCountHigh 0 consumerCountLow 0 bindingCount 1 bindingCountHigh 1 bindingCountLow 1 unackedMessages 0 unackedMessagesHigh 0 unackedMessagesLow 0 messageLatencySamples 0s messageLatencyMin 0s messageLatencyMax 0s messageLatencyAverage 0s b] Session Exceptions are not thrown reliably The exception is triggered on broker side reliably (every times the situation occurs), but just first time on the client side, which is incorrect ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [root@mrg-qe-02 qpid]# ${sender} "q_rep2; {create: always, node: {x-declare:{arguments:{'qpid.max_count':3.14159, 'qpid.max_size': 'flummery'}}}}" --count 5 Traceback (most recent call last): File "/usr/share/doc/python-qpid-0.7.946106/examples/api/spout", line 101, in ? snd = ssn.sender(addr) File "<string>", line 6, in sender File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 577, in sender sender._ewait(lambda: sender.linked) File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 784, in _ewait result = self.session._ewait(lambda: self.error or predicate(), timeout) File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 552, in _ewait self.check_error() File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 541, in check_error raise self.error qpid.messaging.exceptions.SessionError: invalid-argument: Cannot convert qpid.max_count to unsigned integer (qpid/broker/QueuePolicy.cpp:136)(542) [root@mrg-qe-02 qpid]# ${sender} "q_rep2; {create: always, node: {x-declare:{arguments:{'qpid.max_count':3.14159, 'qpid.max_size': 'flummery'}}}}" --count 5 Message(properties={'spout-id': 'a3140362-617e-1c49-a60a-5c7d49048352:0'}) Message(properties={'spout-id': 'a3140362-617e-1c49-a60a-5c7d49048352:1'}) Message(properties={'spout-id': 'a3140362-617e-1c49-a60a-5c7d49048352:2'}) Message(properties={'spout-id': 'a3140362-617e-1c49-a60a-5c7d49048352:3'}) Message(properties={'spout-id': 'a3140362-617e-1c49-a60a-5c7d49048352:4'}) [root@mrg-qe-02 qpid]# echo $? 0 qpidd log says (in both cases SessionError): 2010-11-10 08:04:41 debug periodic update management snapshot: packages: 2 objects: 52 new objects: 0 2010-11-10 08:04:41 debug RECV [127.0.0.1:39274] INIT(0-10) 2010-11-10 08:04:41 debug External ssf=0 and auth= 2010-11-10 08:04:41 debug min_ssf: 0, max_ssf: 256, external_ssf: 0 2010-11-10 08:04:41 info SASL: Mechanism list: LOGIN PLAIN ANONYMOUS CRAM-MD5 DIGEST-MD5 2010-11-10 08:04:41 debug SASL: Starting authentication with mechanism: ANONYMOUS 2010-11-10 08:04:41 info 127.0.0.1:39274 SASL: Authentication succeeded for: anonymous@QPID 2010-11-10 08:04:41 debug SessionState::SessionState anonymous:0: 0x5ef3c80 2010-11-10 08:04:41 debug anonymous:0: attached on broker. 2010-11-10 08:04:41 debug Attached channel 0 to anonymous:0 2010-11-10 08:04:41 debug anonymous:0: ready to send, activating output. 2010-11-10 08:04:41 debug anonymous:0: receiver command-point set to: (0+0) 2010-11-10 08:04:41 debug Exception constructed: Exchange not found: q_rep2 (qpid/broker/ExchangeRegistry.cpp:92) 2010-11-10 08:04:41 debug anonymous:0: receiver marked completed: 0 incomplete: { } unknown-completed: { [0,0] } 2010-11-10 08:04:41 debug anonymous:0: receiver marked completed: 1 incomplete: { } unknown-completed: { [0,1] } 2010-11-10 08:04:41 notice Journal "q_rep2": Created 2010-11-10 08:04:41 debug Journal "q_rep2": Journal directory = "/var/lib/qpidd/rhm/jrnl/0012/q_rep2/"; Base file name = "JournalData" 2010-11-10 08:04:41 debug Journal "q_rep2": Initialize; num_jfiles=8 jfsize_sblks=3072 wcache_pgsize_sblks=64 wcache_num_pages=32 2010-11-10 08:04:42 debug Journal "q_rep2": Initialization complete 2010-11-10 08:04:42 debug Exception constructed: Cannot convert qpid.max_count to unsigned integer (qpid/broker/QueuePolicy.cpp:136) 2010-11-10 08:04:42 error Execution exception: invalid-argument: Cannot convert qpid.max_count to unsigned integer (qpid/broker/QueuePolicy.cpp:136) 2010-11-10 08:04:42 debug anonymous:0: detached on broker. 2010-11-10 08:04:42 debug DISCONNECTED [127.0.0.1:39274] 2010-11-10 08:04:42 debug guest: receiver marked completed: 1420 incomplete: { } unknown-completed: { [0,1420] } 2010-11-10 08:04:42 debug guest: receiver marked completed: 1421 incomplete: { } unknown-completed: { [0,1421] } 2010-11-10 08:04:43 debug RECV [127.0.0.1:39275] INIT(0-10) 2010-11-10 08:04:43 debug External ssf=0 and auth= 2010-11-10 08:04:43 debug min_ssf: 0, max_ssf: 256, external_ssf: 0 2010-11-10 08:04:43 info SASL: Mechanism list: LOGIN PLAIN ANONYMOUS CRAM-MD5 DIGEST-MD5 2010-11-10 08:04:43 debug SASL: Starting authentication with mechanism: ANONYMOUS 2010-11-10 08:04:43 info 127.0.0.1:39275 SASL: Authentication succeeded for: anonymous@QPID 2010-11-10 08:04:43 debug SessionState::SessionState anonymous:0: 0x2aaaac0468c0 2010-11-10 08:04:43 debug anonymous:0: attached on broker. 2010-11-10 08:04:43 debug Attached channel 0 to anonymous:0 2010-11-10 08:04:43 debug anonymous:0: ready to send, activating output. 2010-11-10 08:04:43 debug anonymous:0: receiver command-point set to: (0+0) 2010-11-10 08:04:43 debug Exception constructed: Exchange not found: q_rep2 (qpid/broker/ExchangeRegistry.cpp:92) 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 0 incomplete: { } unknown-completed: { [0,0] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 1 incomplete: { } unknown-completed: { [0,1] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 2 incomplete: { } unknown-completed: { [0,2] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 3 incomplete: { } unknown-completed: { [0,3] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 4 incomplete: { } unknown-completed: { [0,4] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 5 incomplete: { } unknown-completed: { [0,5] } 2010-11-10 08:04:43 debug anonymous:0: receiver marked completed: 6 incomplete: { } unknown-completed: { [0,6] } 2010-11-10 08:04:43 debug anonymous:0: detached on broker. As point a] is in the contrary of the defect definition and point b] to some extend as well, thus I'm moving defect to ... --> ASSIGNED The problem here is that even though the exception is properly thrown by the broker, the queue is still created with default parameters. The subsequent attempts don't fail because the queue create is skipped due to the queue already existing. One consequence of the 'fix' is that qpid-config will fail to list queues if finds incorrect type, see the listing below which explains what is going to happen:
[root@mrg-qe-02 ~]# qpid-config queues
Queue Name Attributes
===========================================================================
message_queue --durable
my-queue --durable Failed: TypeError: int argument required
[root@mrg-qe-02 ~]# ${sender} "my-queuE; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'5'}}}}" --count 10
-bash: my-queuE; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'5'}}}}: command not found
[root@mrg-qe-02 ~]# sender=/usr/share/doc/python-qpid-0.7.946106/examples/api/spout
[root@mrg-qe-02 ~]# ${sender} "my-queuE; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'5'}}}}" --count 10
Message(properties={'spout-id': '5bf65b8f-9894-2b48-8fab-24bfdff9a2fb:0'})
Message(properties={'spout-id': '5bf65b8f-9894-2b48-8fab-24bfdff9a2fb:1'})
Message(properties={'spout-id': '5bf65b8f-9894-2b48-8fab-24bfdff9a2fb:2'})
Message(properties={'spout-id': '5bf65b8f-9894-2b48-8fab-24bfdff9a2fb:3'})
Message(properties={'spout-id': '5bf65b8f-9894-2b48-8fab-24bfdff9a2fb:4'})
resource-limit-exceeded: Policy exceeded on my-queuE, policy: size: max=104857600, current=0; count: max=5, current=5; type=reject (qpid/broker/QueuePolicy.cpp:86)(506)
Traceback (most recent call last):
File "/usr/share/doc/python-qpid-0.7.946106/examples/api/spout", line 123, in ?
conn.close()
File "<string>", line 6, in close
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 301, in close
ssn.close(timeout=timeout)
File "<string>", line 6, in close
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 724, in close
self.sync(timeout=timeout)
File "<string>", line 6, in sync
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 715, in sync
snd.sync(timeout=timeout)
File "<string>", line 6, in sync
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 870, in sync
if not self._ewait(lambda: self.acked >= mno, timeout=timeout):
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 784, in _ewait
result = self.session._ewait(lambda: self.error or predicate(), timeout)
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 552, in _ewait
self.check_error()
File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 541, in check_error
raise self.error
qpid.messaging.exceptions.TargetCapacityExceeded: resource-limit-exceeded: Policy exceeded on my-queuE, policy: size: max=104857600, current=0; count: max=5, current=5; type=reject (qpid/broker/QueuePolicy.cpp:86)(506)
[root@mrg-qe-02 ~]# qpid-config queues
Queue Name Attributes
===========================================================================
message_queue --durable
my-queuE --durable Failed: TypeError: int argument required
The original fix had a couple of problems: (a) it did not check floating point values, (b) the queue was created inspite of throwing an exception.
I have made a further fix that addresses these. The solution to the problem is that valid ints are converted from strings where possible; attempts to use invalid values are logged and the defaults are used instead.
So e.g. spout "my-queue; {create: always, node: {x-declare:
{arguments:{'qpid.max_count':'5'}}}}" --count 10 should result in resource limit exceeded errors, whereas "my-queue; {create: always, node: {x-declare:
{arguments:{'qpid.max_count':'abc'}}}}" --count 10 will not as the default unlimited count will be used. In this case the broker should emit a warning however.
Technical notes still apply.
The additional fix was made upstream (http://svn.apache.org/viewvc?view=revision&revision=1033585) and in the release repo (http://mrg1.lab.bos.redhat.com/git/?p=qpid.git;a=commitdiff;h=2ebd458cd0d300726d83f6410cdd18c464f75fc8).
Tested on RHEL 5.5/48 x x86_64/i386 with
python-qpid-0.7.946106-14
qpid-cpp-client-0.7.946106-20
qpid-cpp-client-devel-0.7.946106-20
qpid-cpp-client-devel-docs-0.7.946106-20
qpid-cpp-client-ssl-0.7.946106-20
qpid-cpp-server-0.7.946106-20
qpid-cpp-server-devel-0.7.946106-20
qpid-cpp-server-ssl-0.7.946106-20
qpid-cpp-server-store-0.7.946106-20
qpid-cpp-server-xml-0.7.946106-20
qpid-java-client-0.7.946106-12
qpid-java-common-0.7.946106-12
qpid-java-example-0.7.946106-12
qpid-tests-0.7.946106-1
qpid-tools-0.7.946106-11
python-qmf-0.7.946106-14
qmf-0.7.946106-20
with commands:
$ sender=/usr/share/doc/python-qpid-0.7.946106/examples/api/spout
$ ${sender} "my-queue1; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'5'}}}}" --count 5
$ ${sender} "my-queue2; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'abc'}}}}" --count 6
$ ${sender} "my-queue3; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'3.14'}}}}" --count 3
$ ${sender} "my-queue4; {create: always, node: {x-declare:{arguments:{'qpid.max_count':'-1'}}}}" --count 3
$ ${sender} "my-queue5; {create: always, node: {x-declare:{arguments:{'qpid.max_count':-1}}}}" --count 3
$ ${sender} "my-queue6; {create: always, node: {x-declare:{arguments:{'qpid.max_count':0}}}}" --count 3
and it works.
There is just one another bug:
I've tried
<snip>
#good
session.queue_declare(queue="queue_capacity1", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': 0})
session.queue_declare(queue="queue_capacity2", exclusive=True, arguments={'qpid.max_count' : 3, 'qpid.max_size': 0})
session.queue_declare(queue="queue_capacity3", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': 300})
session.queue_declare(queue="queue_capacity4", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': "3"})
#bad
session.queue_declare(queue="queue_capacity5", exclusive=True, arguments={'qpid.max_count' : -1, 'qpid.max_size': 0})
session.queue_declare(queue="queue_capacity6", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': -1})
session.queue_declare(queue="queue_capacity7", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': "flummery"})
session.queue_declare(queue="queue_capacity8", exclusive=True, arguments={'qpid.max_count' : 0, 'qpid.max_size': 3.14159})
</snip>
and after these creations of queues "qpid-config queues" doesn't show all these queues(they are visible in qpid-tool).
$ qpid-config queues
Queue Name Attributes
===========================================================================
queue_capacity1 excl --max-queue-size=0 --max-queue-count=0
queue_capacity2 excl --max-queue-size=0 --max-queue-count=3
queue_capacity3 excl --max-queue-size=300 --max-queue-count=0
queue_capacity4 excl Failed: TypeError: int argument required
qpid-config del queue queue_capacity4
$ qpid-config queues
Queue Name Attributes
===========================================================================
queue_capacity1 excl --max-queue-size=0 --max-queue-count=0
queue_capacity2 excl --max-queue-size=0 --max-queue-count=3
queue_capacity3 excl --max-queue-size=300 --max-queue-count=0
queue_capacity5 excl --max-queue-size=0 --max-queue-count=-1
queue_capacity6 excl --max-queue-size=-1 --max-queue-count=0
queue_capacity7 excl Failed: TypeError: int argument required
$ qpid-config del queue queue_capacity7
$ qpid-config queues
Queue Name Attributes
===========================================================================
queue_capacity1 excl --max-queue-size=0 --max-queue-count=0
queue_capacity2 excl --max-queue-size=0 --max-queue-count=3
queue_capacity3 excl --max-queue-size=300 --max-queue-count=0
queue_capacity5 excl --max-queue-size=0 --max-queue-count=-1
queue_capacity6 excl --max-queue-size=-1 --max-queue-count=0
queue_capacity8 excl --max-queue-size=3 --max-queue-count=0
I've filed a bug 653167. One more clarification is needed as current behavior on -20 / -21 surely changed the way that client does not raise exception when invalid value for queue count and queue size.
Despite of above there are multiple observations that default argument are NOT used when invalid parameters are supplied by user.
Let's observe one case closer:
[root@dhcp-27-226 ~]# q_prefix='qu'
[root@dhcp-27-226 ~]# sender=/usr/share/doc/python-qpid-0.7.946106/examples/api/spout
[root@dhcp-27-226 ~]# ${sender} "${q_prefix}q_rep; {create: always, node: {x-declare:{arguments:{'qpid.max_count':3.14159, 'qpid.max_size': 'flummery'}}}}" --count 5 ; echo $?
Message(properties={'spout-id': '7a98ddb9-1012-a449-9989-af66d66eb620:0'})
Message(properties={'spout-id': '7a98ddb9-1012-a449-9989-af66d66eb620:1'})
Message(properties={'spout-id': '7a98ddb9-1012-a449-9989-af66d66eb620:2'})
Message(properties={'spout-id': '7a98ddb9-1012-a449-9989-af66d66eb620:3'})
Message(properties={'spout-id': '7a98ddb9-1012-a449-9989-af66d66eb620:4'})
0
At this point it is fine.
Looking into qpidd log I can see warnings implemented:
[root@dhcp-27-226 ~]# qpidd --log-enable info+ --data-dir /tmp/dd
...
2010-11-16 10:32:47 notice Broker running
2010-11-16 10:33:04 info SASL: Mechanism list: PLAIN LOGIN ANONYMOUS DIGEST-MD5 CRAM-MD5
2010-11-16 10:33:04 info 127.0.0.1:45404 SASL: Authentication succeeded for: anonymous@QPID
2010-11-16 10:33:04 notice Journal "quq_rep": Created
2010-11-16 10:33:05 warning Cannot convert qpid.max_count to unsigned integer, using default (0)
2010-11-16 10:33:05 warning Cannot convert qpid.max_size to unsigned integer, using default (104857600)
2010-11-16 10:33:05 info Queue "quq_rep": Policy created: type=reject; maxCount=0; maxSize=104857600
...
At this point everything is still fine.
The interesting issue I observe is seen in qpid-tool and/or queue database:
[root@dhcp-27-226 ~]# qpid-tool
Management Tool for QPID
qpid: list queue
...
qpid: show 129
Object of type: org.apache.qpid.broker:queue(3a30c319-5ef2-f211-ba1f-4900d5f75435)
Attribute 129
===============================================================================================
vhostRef 139
name quq_rep
durable True
autoDelete False
exclusive False
arguments {u'qpid.max_size': u'flummery', u'qpid.max_count': 3.1415899999999999}
altExchange 140
msgTotalEnqueues 5
msgTotalDequeues 0
msgTxnEnqueues 0
msgTxnDequeues 0
msgPersistEnqueues 0
msgPersistDequeues 0
msgDepth 5
byteDepth 0
...
.../rhm/dat/__db.003 binary search shows:
...................H.......B....quq_rep...5.....qpid.max_count3@ !....n
qpid.max_size...flummery.....
...R...(...ƄH.
Just for completeness, qpid-config fails which is addressed as bug 653167.
[root@dhcp-27-226 ~]# qpid-config queues
Queue Name Attributes
=================================================================
qmfc-v2-dhcp-27-226.brq.redhat.com.2619.1 auto-del excl
qmfc-v2-hb-dhcp-27-226.brq.redhat.com.2619.1 auto-del excl --limit-policy=ring
qmfc-v2-ui-dhcp-27-226.brq.redhat.com.2619.1 auto-del excl --limit-policy=ring
quq_rep --durable Failed: TypeError: int argument required
The clarification I request is:
How I can be sure that queue policy is created correct way if I can see two different values from qpidd log vs. qmf channel and queue database? Is there any other way how to assure that queue policy was created with default values?
Raising NEEDINFO.
The policy values can be tested by trying to exceed them. The values reported by qmf are simply the values that were originally specified. The original issue has been somehow resolved, but there are two uglinesses raised as two separate issues bug 653167 and bug 654020. Tested on RHEL 4.8 / 5.5 i386 / x86_64 on packages: [root@mrg-qe-01 ~]# rpm -qa | grep -E '(qpid|qmf)' | sort python-qmf-0.7.946106-14.el5 python-qpid-0.7.946106-14.el5 qmf-0.7.946106-21.el5 qmf-devel-0.7.946106-21.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-rdma-0.7.946106-21.el5 qpid-cpp-client-ssl-0.7.946106-21.el5 qpid-cpp-mrg-debuginfo-0.7.946106-21.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-rdma-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-dotnet-0.4.738274-2.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 rh-qpid-cpp-tests-0.7.946106-21.el5 ruby-qmf-0.7.946106-21.el5 ruby-qpid-0.7.946106-2.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 updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,7 +1 @@
-Cause: The broker, when receiving arguments for queue creation does not interpret strings as numbers for numeric quantities, even if the string represents a number.
+When receiving arguments for queue creation, the broker did not interpret strings as numbers for numeric quantities even if the string represented a number. As a result, sending numbers as string values in queue-create arguments caused the values to not take affect in the broker. With this update, the broker now properly interprets numeric values even if they are encoded as strings.-
-Consequence: Sending numbers as string values in queue-create arguments causes the values to not take affect in the broker.
-
-Fix: The broker has been updated to properly interpret numeric values even if they are encoded as strings.
-
-Result: The broker is much more tolerant of variances in the way arguments are encoded by client libraries.
|