[
https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696128#comment-13696128
]
Fraser Adams commented on QPID-4969:
------------------------------------
whoah there chuck. I think in principal this is good, however this work has
also caused the perfectly reasonable case of consumer clients reconnecting to
non-exclusive queues to fail.
I just fired up a fairly standard headers exchange C++ consumer that I use as a
bit of a test case, which has the address string:
"testqueue; {create: receiver, node: {x-declare: {arguments:
{'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
[{exchange: 'amq.match', queue: 'testqueue', key: 'data1', arguments: {x-match:
all, data-service: amqp-delivery, item-owner: fadams}}]}}"
This has worked for me since 0.8 and is a pattern I use for most of my
operational subscriptions albeit with different headers. The key thing though
is that I expect the first time I fire this up to create the queue/binding etc.
and subsequently be it when I shut down this consumer and restart it or whether
I stand up additional consumer instances I expect my consumers to retrieve data
off the already created queue/binding. As I say this has worked consistently
since 0.8 and today I'm getting the following when I shut down my consumer then
restart it:
2013-06-29 14:19:58 [Client] warning Exception received from broker:
internal-error: internal-error: Exchange: amq.match, binding key: data1
Duplicate binding key not allowed.
(/home/fadams/qpid/qpid-trunk/qpid/cpp/src/qpid/broker/HeadersExchange.cpp:207)
[caused by 3 \x07:\x04]
ItemProducer Exception: internal-error: internal-error: Exchange: amq.match,
binding key: data1 Duplicate binding key not allowed.
(/home/fadams/qpid/qpid-trunk/qpid/cpp/src/qpid/broker/HeadersExchange.cpp:207)
I'm currently using headers exchange and only testing on AMQP 0.10 built off
trunk using r1497991.
I was going to raise a JIRA relating to this but I noticed this one as I was
typing and this is almost certainly the cause of what I'm currently seeing.
This is a fairly critical regression for me and would cause significant issues
to my operational system as I use the "consumer self service" pattern
(illustrated above in the example address string) for queue
creation/subscription pretty much exclusively.
> C++ Broker headers exchange allows creation of bindings with duplicate keys
> ---------------------------------------------------------------------------
>
> Key: QPID-4969
> URL: https://issues.apache.org/jira/browse/QPID-4969
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.22
> Reporter: Chuck Rolke
> Assignee: Chuck Rolke
> Fix For: 0.23
>
>
> The test case:
> {code}
> qpid-config add queue MyQueue --durable
> qpid-config bind amq.match MyQueue SomeKey any property1=value1
> qpid-config bind amq.match MyQueue SomeKey all property1=value1
> {code}
> Causes a management error as two bindings are created with
> amq.match,MyQueue,SomeKey managementId.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
