[jira] [Commented] (QPID-4958) Java Performance Tests - race condition client registration detection causes tests to hang
[ https://issues.apache.org/jira/browse/QPID-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696660#comment-13696660 ] ASF subversion and git services commented on QPID-4958: --- Commit 1498306 from [~philharveyonline] [ https://svn.apache.org/r1498306 ] QPID-4958: fixed race condition in ClientRegistry that caused awaitClients to hang if all registrations arrive between the initial numberAbsent() call and _lock.wait(). > Java Performance Tests - race condition client registration detection causes > tests to hang > -- > > Key: QPID-4958 > URL: https://issues.apache.org/jira/browse/QPID-4958 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.22 >Reporter: Philip Harvey >Assignee: Philip Harvey > Attachments: > 0001-QPID-4958-fixed-race-condition-in-ClientRegistry-tha.patch > > > Occasionally various tests in ControllerAndClientTest fail with errors such > as: > {noformat} > main 2013-06-25 14:39:25,539 ERROR [qpid.disttest.controller.TestRunner] > Couldn't run test > org.apache.qpid.disttest.DistributedTestException: After 3ms ... Timed > out waiting for command responses ... Expecting 10 more responses. > at > org.apache.qpid.disttest.controller.TestRunner.awaitLatch(TestRunner.java:293) > at > org.apache.qpid.disttest.controller.TestRunner.awaitCommandResponses(TestRunner.java:183) > at > org.apache.qpid.disttest.controller.TestRunner.runParts(TestRunner.java:130) > at org.apache.qpid.disttest.controller.TestRunner.run(TestRunner.java:103) > at > org.apache.qpid.disttest.controller.Controller.runAllTests(Controller.java:171) > at > org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.runTestsForTwoClients(ControllerAndClientTest.java:195) > at > org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.testProducerAndThreeConsumersInSeparateClients(ControllerAndClientTest.java:136) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} > The relevant test log excerpts are shown below. > {noformat} > main 2013-06-25 14:38:35,357 INFO [qpid.disttest.controller.Controller] > Awaiting client registrations > ... > 908 Dispatcher-1-Conn-2 2013-06-25 14:38:35,448 INFO > [qpid.disttest.controller.ClientRegistry] Client registered: > 63a95928-7d12-48ad-9326-133da9a0ddb6 > ... > 920 Dispatcher-1-Conn-2 2013-06-25 14:38:35,450 INFO > [qpid.disttest.controller.ClientRegistry] Client registered: > 2510ce56-20d4-43a2-84db-193a87b1cfec > ... > {noformat} > Client thread timing out after the 5 seconds set by the JUnit test: > {noformat} > 997 2510ce56-20d4-43a2-84db-193a87b1cfec-thread 2013-06-25 14:38:40,423 DEBUG > [apache.qpid.client.AMQSession] Closing session: > org.apache.qpid.client.AMQSes sion_0_8@5e111b5c > {noformat} > Controller sends test set-up commands, 20 seconds after "Awaiting client > registrations". This happens to be the length of the client registration > time-out, suggesting that the "await client registrations" code didn't notice > that client registrations. > {noformat} > 1080 main 2013-06-25 14:38:55,476 DEBUG [qpid.disttest.controller.TestRunner] > About to send 10 command(s) > {noformat} -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: provide means of configuring subscription queues for 'topics' over AMQP 1.0
On 06/29/2013 03:47 PM, Fraser Adams wrote: Some of this is making me a little nervous in particular the response around my headers Address String, but I might me misunderstanding e.g. "That would now be handled in two steps. The first is a configuration step whereby a 'topic' is created referencing amq.match and specifying the desired 'policy' for subscription queues for that topic. E.g. qpidt create topic amq.match.default exchange=amq.match qpid.policy_type=ring qpid.max_size=5" So this is using your new qpidt utility (what does qpidt stand for BTW?) to create a "topic" called amq.match.default referencing amq.match with the specified policy - correct? I'm not entirely sure what a "topic" really relates to in the AMQP 1.0 sense but that's probably a separate question There isn't an explicit concept of 'topic' in the AMQP 1.0 specification. I'm using that term in the JMS sense. (Note that previous versions of AMQP did not had any explicit notion of topic either). "Then you would create your receiver using an address that referenced the topic created, and specifying the filter instead of the x-bindings. E.g. amq.match.default; {link:{filter:{value:x-match:all,data-service: amqp-delivery, item-owner: fadams},name:data1,descriptor:"apache.org:legacy-amqp-headers-binding:map"}}}" So this is using the "amq.match.default" topic in essence as a factory and will create a subscription using what amounts to the same header matches as my previous example using a 500K ring queue - correct? Correct. Essentially it is a way to identify the exchange and the set of desired subscription queue properties simply through the node name. (also allowing different sets of properties for different use cases. So far so good, but in my example: "testqueue; {create: receiver, node: {x-declare: {arguments: {'qpid.policy_type': ring, 'qpid.max_size': 5}}, x-bindings: [{exchange: 'amq.match', queue: 'testqueue', key: 'data1', arguments: {x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}" The fact that the queue had a particular name is significant! So in this example the first consumer to create a destination with this Address String causes a queue called "testqueue" to be created and binds it to the headers exchange using the bindings specified in the x-bindings. But (significantly for my use cases!) if that consumer were to close down and restart it would simply reconnect to "testqueue" consuming any messages that may have been left on it. Moreover if my consumer were to note that the queue depth was rising too much I could scale out additional instances which again would simply consume off "testqueue". The first part is where the subscription continues to exist even when there are no active links. I.e. something like a durable subscription in the JMS sense, which you get by specifying durable:True in your link properties (which in AMQP 1.0 is translated into the terminus durability). The second part is the notion of a 'shared' subscription. You can specify a name in your link and request the 'shared' node capability. This capability is specific to qpidd at present, but is simple and obvious enough that I could see it being more widely adopted. (In the case of qpidd the queue name will match the link name). So the address might look like: amq.match.default; {link:{durable:true, name:testqueue, filter:{value:x-match:all,data-service: amqp-delivery, item-owner: fadams},name:data1,descriptor:"apache.org:legacy-amqp-headers-binding:map"}}, node:{capabilities:[shared]}}" I guess what I'm saying is that the following use cases are significant for me: a) The ability to use *named* non-exclusive queue where consumers can come and go and multiple consumers may be attached for scaling purposes. That is supported through the concept of shared subscriptions (orthogonal to the use of 'topic' as factory for subscription queues of a particular configuration). b) My consumers operate in a "self-service" model, so a consumer creates a destination via an Address String and that string may specify the queue we wish to create. The name of the subscription is currently identified by the name of the link. Note that the specification requires the name of the link to be unique for the pair of containers it connects, i.e. you can't have more than one sender/receiver with the same link name over the same connection. Supporting a special link property to identify the shared subscription in cases where this restriction is not acceptable (e.g. JMS 2.0) is I think a reasonable extension. c) There may be a non-trivial number of logical consumers, each of which may use different queue names and each may or may not need to scale out to multiple instances consuming of a given queue. You could have multiple, distinct shared subscriptions (each identified by a different name). I'd be happy enough with the idea of "administratively" creating what amounts to a sing
[jira] [Resolved] (QPID-4958) Java Performance Tests - race condition client registration detection causes tests to hang
[ https://issues.apache.org/jira/browse/QPID-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4958. - Resolution: Fixed Fix Version/s: 0.23 > Java Performance Tests - race condition client registration detection causes > tests to hang > -- > > Key: QPID-4958 > URL: https://issues.apache.org/jira/browse/QPID-4958 > Project: Qpid > Issue Type: Bug > Components: Java Performance Tests >Affects Versions: 0.22 >Reporter: Philip Harvey >Assignee: Philip Harvey > Fix For: 0.23 > > Attachments: > 0001-QPID-4958-fixed-race-condition-in-ClientRegistry-tha.patch > > > Occasionally various tests in ControllerAndClientTest fail with errors such > as: > {noformat} > main 2013-06-25 14:39:25,539 ERROR [qpid.disttest.controller.TestRunner] > Couldn't run test > org.apache.qpid.disttest.DistributedTestException: After 3ms ... Timed > out waiting for command responses ... Expecting 10 more responses. > at > org.apache.qpid.disttest.controller.TestRunner.awaitLatch(TestRunner.java:293) > at > org.apache.qpid.disttest.controller.TestRunner.awaitCommandResponses(TestRunner.java:183) > at > org.apache.qpid.disttest.controller.TestRunner.runParts(TestRunner.java:130) > at org.apache.qpid.disttest.controller.TestRunner.run(TestRunner.java:103) > at > org.apache.qpid.disttest.controller.Controller.runAllTests(Controller.java:171) > at > org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.runTestsForTwoClients(ControllerAndClientTest.java:195) > at > org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.testProducerAndThreeConsumersInSeparateClients(ControllerAndClientTest.java:136) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} > The relevant test log excerpts are shown below. > {noformat} > main 2013-06-25 14:38:35,357 INFO [qpid.disttest.controller.Controller] > Awaiting client registrations > ... > 908 Dispatcher-1-Conn-2 2013-06-25 14:38:35,448 INFO > [qpid.disttest.controller.ClientRegistry] Client registered: > 63a95928-7d12-48ad-9326-133da9a0ddb6 > ... > 920 Dispatcher-1-Conn-2 2013-06-25 14:38:35,450 INFO > [qpid.disttest.controller.ClientRegistry] Client registered: > 2510ce56-20d4-43a2-84db-193a87b1cfec > ... > {noformat} > Client thread timing out after the 5 seconds set by the JUnit test: > {noformat} > 997 2510ce56-20d4-43a2-84db-193a87b1cfec-thread 2013-06-25 14:38:40,423 DEBUG > [apache.qpid.client.AMQSession] Closing session: > org.apache.qpid.client.AMQSes sion_0_8@5e111b5c > {noformat} > Controller sends test set-up commands, 20 seconds after "Awaiting client > registrations". This happens to be the length of the client registration > time-out, suggesting that the "await client registrations" code didn't notice > that client registrations. > {noformat} > 1080 main 2013-06-25 14:38:55,476 DEBUG [qpid.disttest.controller.TestRunner] > About to send 10 command(s) > {noformat} -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4970) [Java Broker] Configure MessageStores based on VirtualHost object not XML Configuration
Rob Godfrey created QPID-4970: - Summary: [Java Broker] Configure MessageStores based on VirtualHost object not XML Configuration Key: QPID-4970 URL: https://issues.apache.org/jira/browse/QPID-4970 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey As part of the migration from the XML configuration files to a more generic configuration mechanism, change the primary configuration mechanism of MessageStores from XML to using the VirtualHost model object. Compatibility with existing XML config should be maintained -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4970) [Java Broker] Configure MessageStores based on VirtualHost object not XML Configuration
[ https://issues.apache.org/jira/browse/QPID-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696681#comment-13696681 ] ASF subversion and git services commented on QPID-4970: --- Commit 1498345 from [~godfrer] [ https://svn.apache.org/r1498345 ] QPID-4970 : [Java Broker] Configure MessageStores based on VirtualHost object not XML Configuration > [Java Broker] Configure MessageStores based on VirtualHost object not XML > Configuration > --- > > Key: QPID-4970 > URL: https://issues.apache.org/jira/browse/QPID-4970 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > As part of the migration from the XML configuration files to a more generic > configuration mechanism, change the primary configuration mechanism of > MessageStores from XML to using the VirtualHost model object. Compatibility > with existing XML config should be maintained -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696748#comment-13696748 ] Gordon Sim commented on QPID-4969: -- This also breaks the unit tests, though in that case it is the test itself that is really at fault. Since unbind works only on the binding key (not the args), I think it is generally good to disallow different bindings to the same queue with the same key. Any use case that relied on *different* args and the same key would I think already be subtly (sometimes not so subtly!) broken. The issue with the change as it stands is I think simply that a bind is no longer idempotent, i.e. you should not prevent the same binding being requested (you don't actually need to do anything for it though, since it is already in place). So the thrid command in the reproducer above _should_ fail, but just reissuing the second command should not. Suggested change: {noformat} Index: src/qpid/broker/HeadersExchange.cpp === --- src/qpid/broker/HeadersExchange.cpp (revision 1498354) +++ src/qpid/broker/HeadersExchange.cpp (working copy) @@ -200,8 +200,10 @@ Bindings::ConstPtr p = bindings.snapshot(); if (p.get()) { +MatchArgs matchArgs(queue, &extra_args); +MatchKey matchKey(queue, bindingKey); for (std::vector::const_iterator i = p->begin(); i != p->end(); ++i) { -if (queue == i->binding->queue && bindingKey == i->binding->key) { +if (matchKey(*i) && matchArgs(*i)) { throw InternalErrorException(QPID_MSG("Exchange: " << getName() << ", binding key: " << bindingKey << " Duplicate binding key not allowed." )); @@ -372,7 +374,7 @@ //- HeadersExchange::MatchArgs::MatchArgs(Queue::shared_ptr q, const qpid::framing::FieldTable* a) : queue(q), args(a) {} -bool HeadersExchange::MatchArgs::operator()(BoundKey & bk) +bool HeadersExchange::MatchArgs::operator()(const BoundKey & bk) { return bk.binding->queue == queue && bk.binding->args == *args; } @@ -380,7 +382,7 @@ //- HeadersExchange::MatchKey::MatchKey(Queue::shared_ptr q, const std::string& k) : queue(q), key(k) {} -bool HeadersExchange::MatchKey::operator()(BoundKey & bk) +bool HeadersExchange::MatchKey::operator()(const BoundKey & bk) { return bk.binding->queue == queue && bk.binding->key == key; } Index: src/qpid/broker/HeadersExchange.h === --- src/qpid/broker/HeadersExchange.h (revision 1498354) +++ src/qpid/broker/HeadersExchange.h (working copy) @@ -48,7 +48,7 @@ const Queue::shared_ptr queue; const qpid::framing::FieldTable* args; MatchArgs(Queue::shared_ptr q, const qpid::framing::FieldTable* a); -bool operator()(BoundKey & bk); +bool operator()(const BoundKey & bk); }; struct MatchKey @@ -56,7 +56,7 @@ const Queue::shared_ptr queue; const std::string& key; MatchKey(Queue::shared_ptr q, const std::string& k); -bool operator()(BoundKey & bk); +bool operator()(const BoundKey & bk); }; struct FedUnbindModifier {noformat} > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696750#comment-13696750 ] Gordon Sim commented on QPID-4969: -- The test should also be fixed, e.g.: {noformat} Index: src/tests/ExchangeTest.cpp === --- src/tests/ExchangeTest.cpp (revision 1498354) +++ src/tests/ExchangeTest.cpp (working copy) @@ -138,7 +138,7 @@ args3.setInt("b", 6); headers.bind(a, "", &args1); -headers.bind(a, "", &args3); +headers.bind(a, "other", &args3);//need to use different binding key to correctly identify second binding headers.bind(b, "", &args2); headers.bind(c, "", &args1); {noformat} > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Remove autotools build for C++ build
> > [X] * When 0.25 opens after the 0.24 beta branch remove the C++ > qpid autotools build infrastructure in favour of the cmake tools. > * A heads up message to the user mailing list. > * Add a release note to 0.24 to say it is the last release that will > contain an autotools build. > * Add a release note to 0.26 to say that only cmake is available > from this release forward > [ ] We're not ready for this yet, here's why: > -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Remove autotools build for C++ build
[ x ] * When 0.25 opens after the 0.24 beta branch remove the C++ qpid autotools build infrastructure in favour of the cmake tools. On 27 June 2013 05:40, Andrew Stitcher wrote: > In March this year we had a discussion about removing finally switching > from autotools to cmake in the C++ build. > > The consensus as I understand it was to change the documentation to > prefer cmake in 0.22, including printing a deprecation notice if you use > autotools (which was done). > > Then for 0.24 make failure to build with cmake a blocking issue - we are > at this point now. So people show be doing as much of their testing as > possible with cmake based builds. > > Then actually remove the autotools build for 0.26. I'd plan to do this > pretty soon after we branch 0.24 for beta on the opened 0.25 trunk. This > way we will have a good few months to fix any problem before the 0.26 > release. > > So I call for a vote: > > [ ] * When 0.25 opens after the 0.24 beta branch remove the C++ > qpid autotools build infrastructure in favour of the cmake tools. > * A heads up message to the user mailing list. > * Add a release note to 0.24 to say it is the last release that will > contain an autotools build. > * Add a release note to 0.26 to say that only cmake is available > from this release forward > [ ] We're not ready for this yet, here's why: > > > > Thanks > > Andrew > > > [1] > > http://apache-qpid-developers.2158895.n2.nabble.com/Proposal-get-rid-of-automake-build-system-tt7585130.html > > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
New Defects reported by Coverity Scan for Apache-Qpid
Hi, Please find the latest report on new defect(s) introduced to Apache-Qpid found with Coverity Scan Defect(s) Reported-by: Coverity Scan ** CID 1040638: Mixing enum types (MIXED_ENUMS) /qpidbuilds/trunk/qpid/cpp/src/qpid/acl/AclData.cpp: 184 ** CID 1040637: Missing unlock (LOCK) /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 386 CID 1040638: Mixing enum types (MIXED_ENUMS) /qpidbuilds/trunk/qpid/cpp/src/qpid/acl/AclData.cpp: 184 ( mixed_enums) 181break; 182 183default: >>> CID 1040638: Mixing enum types (MIXED_ENUMS) >>> Mixing enum types qpid::acl::Property and qpid::acl::SpecProperty for >>> "". 184lookupParamItr = params->find((Property)rulePropMapItr->first); 185break; 186}; 187 188if (lookupParamItr == params->end()) { CID 1040637: Missing unlock (LOCK) /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 379 ( lock) 376 377void Connection::doIoCallbacks() { 378if (!isOpen()) return; // Don't process IO callbacks until we are open. >>> "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mutex &)" >>> locks "this->ioCallbackLock.mutex". 379ScopedLock l(ioCallbackLock); 380while (!ioCallbacks.empty()) { 381boost::function0 cb = ioCallbacks.front(); 382ioCallbacks.pop(); 383ScopedUnlock ul(ioCallbackLock); /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 386 ( missing_unlock) 383ScopedUnlock ul(ioCallbackLock); 384cb(); // Lend the IO thread for management processing 385} >>> CID 1040637: Missing unlock (LOCK) >>> Returning without unlocking "this->ioCallbackLock.mutex". 386} 387 388bool Connection::doOutput() { 389try { 390doIoCallbacks(); To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696920#comment-13696920 ] Chuck Rolke commented on QPID-4969: --- Gordon's patch (thanks for that!) still fails Fraser's case. I propose something to satisfy both camps: When a binding with a duplicate key and duplicate args comes up then just pass on it. Don't create a new binding nor complain just let the old binding continue to exist. When a binding with a duplicate key but different args comes up then it gets failed. This means that one binding can't specify 'any' and another specify 'all' but have both survive with the same key. This scheme gets Fraser's test case to pass but still fails this issue's test case. {noformat} Index: cpp/src/tests/ExchangeTest.cpp === --- cpp/src/tests/ExchangeTest.cpp (revision 1498469) +++ cpp/src/tests/ExchangeTest.cpp (working copy) @@ -138,7 +138,7 @@ args3.setInt("b", 6); headers.bind(a, "", &args1); -headers.bind(a, "", &args3); +headers.bind(a, "other", &args3);//need to use different binding key to correctly identify second binding headers.bind(b, "", &args2); headers.bind(c, "", &args1); Index: cpp/src/qpid/broker/HeadersExchange.h === --- cpp/src/qpid/broker/HeadersExchange.h (revision 1498469) +++ cpp/src/qpid/broker/HeadersExchange.h (working copy) @@ -48,7 +48,7 @@ const Queue::shared_ptr queue; const qpid::framing::FieldTable* args; MatchArgs(Queue::shared_ptr q, const qpid::framing::FieldTable* a); -bool operator()(BoundKey & bk); +bool operator()(const BoundKey & bk); }; struct MatchKey @@ -56,7 +56,7 @@ const Queue::shared_ptr queue; const std::string& key; MatchKey(Queue::shared_ptr q, const std::string& k); -bool operator()(BoundKey & bk); +bool operator()(const BoundKey & bk); }; struct FedUnbindModifier Index: cpp/src/qpid/broker/HeadersExchange.cpp === --- cpp/src/qpid/broker/HeadersExchange.cpp (revision 1498469) +++ cpp/src/qpid/broker/HeadersExchange.cpp (working copy) @@ -189,7 +189,7 @@ // the non federation args in case a federated propagate is needed FieldTable extra_args; getNonFedArgs(args, extra_args); - + if (fedOp.empty() || fedOp == fedOpBind) { // x-match arg MUST be present for a bind call std::string x_match_value = getMatch(args); @@ -198,18 +198,31 @@ throw InternalErrorException(QPID_MSG("Invalid or missing x-match value binding to headers exchange. Must be a string [\"all\" or \"any\"]")); } +bool duplicateBinding(false); Bindings::ConstPtr p = bindings.snapshot(); if (p.get()) { +MatchArgs matchArgs(queue, &extra_args); +MatchKey matchKey(queue, bindingKey); for (std::vector::const_iterator i = p->begin(); i != p->end(); ++i) { -if (queue == i->binding->queue && bindingKey == i->binding->key) { -throw InternalErrorException(QPID_MSG("Exchange: " << getName() -<< ", binding key: " << bindingKey -<< " Duplicate binding key not allowed." )); +if (matchKey(*i)) { +// bindings with same keys may be duplicates +if (matchArgs(*i)) { +// duplicate bindings (same key, args) are not added anew +duplicateBinding = true; +} else { +// bindings with same key but different args are not allowed +throw InternalErrorException(QPID_MSG("Exchange: " << getName() +<< ", binding key: " << bindingKey +<< " Duplicate binding key not allowed." )); +} +break; +} else { +// bindings with different keys are not duplicates } } } -{ +if (!duplicateBinding) { Mutex::ScopedLock l(lock); //NOTE: do not include the fed op/tags/origin in the //arguments as when x-match is 'all' these would prevent @@ -372,7 +385,7 @@ //- HeadersExchange::MatchArgs::MatchArgs(Queue::shared_ptr q, const qpid::framing::FieldTable* a) : queue(q), args(a) {} -bool HeadersExchange::MatchArgs::operator()(BoundKey & bk) +bool HeadersExchange::MatchArgs::operator()(const BoundKey & bk) { return bk.binding->queue == queue && bk.binding->args == *args; } @@ -380,7 +393,7 @@ //- HeadersExchange::M
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696947#comment-13696947 ] Gordon Sim commented on QPID-4969: -- Actually... I take that back. I'm not sure it is correct to skip the addOrigin() if the binding matches, is it? Before this issue, if the arguments matched for that queue, the binding would not be added but addOrigin() would be called instead. Now, I don't really understand the fedOrigin stuff, but it would probably be worth having an explicit reason to change the previous behaviour there (which is independent from refusing to allow the same key to be used for different args). > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696936#comment-13696936 ] Gordon Sim commented on QPID-4969: -- My patch _does_ fix Fraser's case (at least as far as I understand it). I.e. I can run two receivers with the address string he gave either in parallel or one after the other, without error. The only difference I see with your patch is that it explicitly skips the actual bind step (the add_unless would fail anyway, but I suppose it is clearer to skip it, especially with the fedOrigin nonsense). So I agree with your modification, I'm just confused as to the given reason for it. > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: New Defects reported by Coverity Scan for Apache-Qpid
Unless I'm missing something subtle, this appears to be a false positive. Coverity marked a few uses of ScopedLock with this error, but not all, which seems curious. -K - Forwarded Message - > From: scan-ad...@coverity.com > To: dev@qpid.apache.org > Sent: Sunday, June 30, 2013 5:39:43 PM > Subject: New Defects reported by Coverity Scan for Apache-Qpid > > > > CID 1040637: Missing unlock (LOCK) > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 379 ( > lock) >376 >377void Connection::doIoCallbacks() { >378if (!isOpen()) return; // Don't process IO callbacks until we >are open. > >>> "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mutex &)" > >>> locks "this->ioCallbackLock.mutex". >379ScopedLock l(ioCallbackLock); >380while (!ioCallbacks.empty()) { >381boost::function0 cb = ioCallbacks.front(); >382ioCallbacks.pop(); >383ScopedUnlock ul(ioCallbackLock); > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 386 ( > missing_unlock) >383ScopedUnlock ul(ioCallbackLock); >384cb(); // Lend the IO thread for management processing >385} > >>> CID 1040637: Missing unlock (LOCK) > >>> Returning without unlocking "this->ioCallbackLock.mutex". >386} >387 >388bool Connection::doOutput() { >389try { >390doIoCallbacks(); > > > To view the defects in Coverity Scan visit, http://scan.coverity.com > > To unsubscribe from the email notification for new defects, > http://scan5.coverity.com/cgi-bin/unsubscribe.py > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
RE: New Defects reported by Coverity Scan for Apache-Qpid
I agree, Ken. If anyone knows how to make Coverity stop this, please let me know. Else I'll check into it. I know there are a few ways to mark things as false positive. > -Original Message- > From: Ken Giusti [mailto:kgiu...@redhat.com] > Sent: Monday, July 01, 2013 1:17 PM > To: Qpid Dev > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > Unless I'm missing something subtle, this appears to be a false positive. > > Coverity marked a few uses of ScopedLock with this error, but not all, which > seems curious. > > -K > > > - Forwarded Message - > > From: scan-ad...@coverity.com > > To: dev@qpid.apache.org > > Sent: Sunday, June 30, 2013 5:39:43 PM > > Subject: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > > > > __ > > > __ > > CID 1040637: Missing unlock (LOCK) > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > 379 ( > > lock) > >376 > >377void Connection::doIoCallbacks() { > >378if (!isOpen()) return; // Don't process IO callbacks until we > >are open. > > >>> > "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mutex > &)" > > >>> locks "this->ioCallbackLock.mutex". > >379ScopedLock l(ioCallbackLock); > >380while (!ioCallbacks.empty()) { > >381boost::function0 cb = ioCallbacks.front(); > >382ioCallbacks.pop(); > >383ScopedUnlock ul(ioCallbackLock); > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > 386 ( > > missing_unlock) > >383ScopedUnlock ul(ioCallbackLock); > >384cb(); // Lend the IO thread for management processing > >385} > > >>> CID 1040637: Missing unlock (LOCK) Returning without unlocking > > >>> "this->ioCallbackLock.mutex". > >386} > >387 > >388bool Connection::doOutput() { > >389try { > >390doIoCallbacks(); > > > > > __ > > > __ To view the defects in Coverity Scan visit, > > http://scan.coverity.com > > > > To unsubscribe from the email notification for new defects, > > http://scan5.coverity.com/cgi-bin/unsubscribe.py > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > commands, e-mail: dev-h...@qpid.apache.org
Re: New Defects reported by Coverity Scan for Apache-Qpid
Hi Steve, I've marked that particular error as "false positive" in Coverity Connect, but from what I can tell, the "right" way to fix such lock wrapper classes is to create a "model" for those wrapper classes. There's some documentation here: http://scan5.coverity.com:8080/docs/en/cov_checker_ref.html#static_c_checker_LOCK Is there a way to configure a model file for the coverity checker? A quick look at our project page on the coverity web site didn't seem to allow that. - Original Message - > From: "Steve Huston" > To: dev@qpid.apache.org > Sent: Monday, July 1, 2013 1:18:58 PM > Subject: RE: New Defects reported by Coverity Scan for Apache-Qpid > > I agree, Ken. If anyone knows how to make Coverity stop this, please let me > know. Else I'll check into it. I know there are a few ways to mark things as > false positive. > > > -Original Message- > > From: Ken Giusti [mailto:kgiu...@redhat.com] > > Sent: Monday, July 01, 2013 1:17 PM > > To: Qpid Dev > > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > > > Unless I'm missing something subtle, this appears to be a false positive. > > > > Coverity marked a few uses of ScopedLock with this error, but not all, > > which > > seems curious. > > > > -K > > > > > > - Forwarded Message - > > > From: scan-ad...@coverity.com > > > To: dev@qpid.apache.org > > > Sent: Sunday, June 30, 2013 5:39:43 PM > > > Subject: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > > > > > > > > > > __ > > > > > __ > > > CID 1040637: Missing unlock (LOCK) > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > 379 ( > > > lock) > > >376 > > >377void Connection::doIoCallbacks() { > > >378if (!isOpen()) return; // Don't process IO callbacks until > > >we > > >are open. > > > >>> > > "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mutex > > &)" > > > >>> locks "this->ioCallbackLock.mutex". > > >379ScopedLock l(ioCallbackLock); > > >380while (!ioCallbacks.empty()) { > > >381boost::function0 cb = ioCallbacks.front(); > > >382ioCallbacks.pop(); > > >383ScopedUnlock ul(ioCallbackLock); > > > > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > 386 ( > > > missing_unlock) > > >383ScopedUnlock ul(ioCallbackLock); > > >384cb(); // Lend the IO thread for management processing > > >385} > > > >>> CID 1040637: Missing unlock (LOCK) Returning without unlocking > > > >>> "this->ioCallbackLock.mutex". > > >386} > > >387 > > >388bool Connection::doOutput() { > > >389try { > > >390doIoCallbacks(); > > > > > > > > __ > > > > > __ To view the defects in Coverity Scan visit, > > > http://scan.coverity.com > > > > > > To unsubscribe from the email notification for new defects, > > > http://scan5.coverity.com/cgi-bin/unsubscribe.py > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > > commands, e-mail: dev-h...@qpid.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: New Defects reported by Coverity Scan for Apache-Qpid
That particular ScopedLock had a ScopedUnlock inside its scope. I wonder if that is leading Coverity astray. -Ted On 07/01/2013 01:16 PM, Ken Giusti wrote: Unless I'm missing something subtle, this appears to be a false positive. Coverity marked a few uses of ScopedLock with this error, but not all, which seems curious. -K - Forwarded Message - From: scan-ad...@coverity.com To: dev@qpid.apache.org Sent: Sunday, June 30, 2013 5:39:43 PM Subject: New Defects reported by Coverity Scan for Apache-Qpid CID 1040637: Missing unlock (LOCK) /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 379 ( lock) 376 377void Connection::doIoCallbacks() { 378if (!isOpen()) return; // Don't process IO callbacks until we are open. "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mutex &)" locks "this->ioCallbackLock.mutex". 379ScopedLock l(ioCallbackLock); 380while (!ioCallbacks.empty()) { 381boost::function0 cb = ioCallbacks.front(); 382ioCallbacks.pop(); 383ScopedUnlock ul(ioCallbackLock); /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: 386 ( missing_unlock) 383ScopedUnlock ul(ioCallbackLock); 384cb(); // Lend the IO thread for management processing 385} CID 1040637: Missing unlock (LOCK) Returning without unlocking "this->ioCallbackLock.mutex". 386} 387 388bool Connection::doOutput() { 389try { 390doIoCallbacks(); To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
RE: New Defects reported by Coverity Scan for Apache-Qpid
Yes, there is a way - I can do it, probably because I'm the admin for the project. If you create one, I'll set it up. > -Original Message- > From: Ken Giusti [mailto:kgiu...@redhat.com] > Sent: Monday, July 01, 2013 2:11 PM > To: dev@qpid.apache.org > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > Hi Steve, > > I've marked that particular error as "false positive" in Coverity Connect, but > from what I can tell, the "right" way to fix such lock wrapper classes is to > create a "model" for those wrapper classes. There's some documentation > here: > > http://scan5.coverity.com:8080/docs/en/cov_checker_ref.html#static_c_ch > ecker_LOCK > > > Is there a way to configure a model file for the coverity checker? A quick > look > at our project page on the coverity web site didn't seem to allow that. > > > - Original Message - > > From: "Steve Huston" > > To: dev@qpid.apache.org > > Sent: Monday, July 1, 2013 1:18:58 PM > > Subject: RE: New Defects reported by Coverity Scan for Apache-Qpid > > > > I agree, Ken. If anyone knows how to make Coverity stop this, please > > let me know. Else I'll check into it. I know there are a few ways to > > mark things as false positive. > > > > > -Original Message- > > > From: Ken Giusti [mailto:kgiu...@redhat.com] > > > Sent: Monday, July 01, 2013 1:17 PM > > > To: Qpid Dev > > > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > Unless I'm missing something subtle, this appears to be a false positive. > > > > > > Coverity marked a few uses of ScopedLock with this error, but not > > > all, which seems curious. > > > > > > -K > > > > > > > > > - Forwarded Message - > > > > From: scan-ad...@coverity.com > > > > To: dev@qpid.apache.org > > > > Sent: Sunday, June 30, 2013 5:39:43 PM > > > > Subject: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > > > > > > > > > > > > > > > > > __ > > > > > > > __ > > > > CID 1040637: Missing unlock (LOCK) > > > > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > > 379 ( > > > > lock) > > > >376 > > > >377void Connection::doIoCallbacks() { > > > >378if (!isOpen()) return; // Don't process IO callbacks until > > > >we > > > >are open. > > > > >>> > > > "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mute > > > x > > > &)" > > > > >>> locks "this->ioCallbackLock.mutex". > > > >379ScopedLock l(ioCallbackLock); > > > >380while (!ioCallbacks.empty()) { > > > >381boost::function0 cb = ioCallbacks.front(); > > > >382ioCallbacks.pop(); > > > >383ScopedUnlock ul(ioCallbackLock); > > > > > > > > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > > 386 ( > > > > missing_unlock) > > > >383ScopedUnlock ul(ioCallbackLock); > > > >384cb(); // Lend the IO thread for management processing > > > >385} > > > > >>> CID 1040637: Missing unlock (LOCK) Returning without unlocking > > > > >>> "this->ioCallbackLock.mutex". > > > >386} > > > >387 > > > >388bool Connection::doOutput() { > > > >389try { > > > >390doIoCallbacks(); > > > > > > > > > > > > __ > > > > > > > __ To view the defects in Coverity Scan visit, > > > > http://scan.coverity.com > > > > > > > > To unsubscribe from the email notification for new defects, > > > > http://scan5.coverity.com/cgi-bin/unsubscribe.py > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For > > > additional commands, e-mail: dev-h...@qpid.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > > commands, e-mail: dev-h...@qpid.apache.org > > > > -- > -K > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4971) C++ Broker queue settings have uninitialized variables
Chuck Rolke created QPID-4971: - Summary: C++ Broker queue settings have uninitialized variables Key: QPID-4971 URL: https://issues.apache.org/jira/browse/QPID-4971 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 0.23 File size limits for ACL are unitialized. The problem appears during ACL lookups: 2013-06-17 17:42:00 [Security] debug ACL: Lookup for id:usera@QPID action:create objectType:queue name:testq with params { durable=false autodelete=false exclusive=false alternate= policytype=reject maxqueuesize=0 maxqueuecount=0 maxfilesize=48794453446331572 maxfilecount=13119085654258853640 } -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4971) C++ Broker queue settings have uninitialized variables
[ https://issues.apache.org/jira/browse/QPID-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697084#comment-13697084 ] ASF subversion and git services commented on QPID-4971: --- Commit 1498630 from c...@apache.org [ https://svn.apache.org/r1498630 ] QPID-4971: Uninitialized variables in QueueSettings > C++ Broker queue settings have uninitialized variables > -- > > Key: QPID-4971 > URL: https://issues.apache.org/jira/browse/QPID-4971 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.20 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.23 > > > File size limits for ACL are unitialized. The problem appears during ACL > lookups: > 2013-06-17 17:42:00 [Security] debug ACL: > Lookup for id:usera@QPID > action:create > objectType:queue name:testq with params { > durable=false > autodelete=false > exclusive=false > alternate= > policytype=reject > maxqueuesize=0 > maxqueuecount=0 > maxfilesize=48794453446331572 > maxfilecount=13119085654258853640 } -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4943) [Java Broker] Introduce a feature for 0-8/0-9/0-9-1protocols to close a connection on receiving a mandatory unroutable message in a transacted session
[ https://issues.apache.org/jira/browse/QPID-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697095#comment-13697095 ] ASF subversion and git services commented on QPID-4943: --- Commit 1498641 from [~godfrer] [ https://svn.apache.org/r1498641 ] QPID-4943: Introduce a feature for 0-8/0-9/0-9-1 protocols to close a connection on receiving a mandatory unroutable message in a transacted session > [Java Broker] Introduce a feature for 0-8/0-9/0-9-1protocols to close a > connection on receiving a mandatory unroutable message in a transacted session > -- > > Key: QPID-4943 > URL: https://issues.apache.org/jira/browse/QPID-4943 > Project: Qpid > Issue Type: New Feature > Components: Java Broker, Java Client >Affects Versions: 0.23 >Reporter: Alex Rudyy >Assignee: Robbie Gemmell > Fix For: 0.23 > > > With AMQP 0-8/0-9/-9-1 protocols sending a message with a routing key for > which no queue binding exist results in either message being bounced back > (mandatory or immediate message) or discarded on broker side (not mandatory > or immediate message). > When a 'mandatory' message is returned back, an AMQNoRouteException is passes > through the configured ExceptionListener on the Connection. This exception > does not cause channel or connection close. However, it require a special > exception handling on client side in order to deal with AMQNoRouteExceptions. > This could potentially be a problem when using various messaging frameworks > and buses (e.g Mule) as they usually close the connection on receiving any > JMSException. > In order to simplify application handling of scenarios where 'mandatory' > messages are being sent to queues which do not actually exist, the Qpid Java > Broker should allow configuring the client/broker on a global and/or > connection-specific basis such that the broker should respond to this > situation by closing the connection rather than returning the unroutable > message to the client. -- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697113#comment-13697113 ] Chuck Rolke commented on QPID-4969: --- We need to call the federation addOrigin function as you are correctly concerned. In your original patch I think you meant {noformat} +if (matchKey(*i) && !matchArgs(*i)) { {noformat} where you left out the "!". > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4969) C++ Broker headers exchange allows creation of bindings with duplicate keys
[ https://issues.apache.org/jira/browse/QPID-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697139#comment-13697139 ] ASF subversion and git services commented on QPID-4969: --- Commit 1498671 from c...@apache.org [ https://svn.apache.org/r1498671 ] QPID-4969: C++ Broker headers exchange allows creation of bindings with duplicate keys Patch from Gordon Sim to correct issues in initial fix. Now successive bind requests are accepted when the key, queue, and exchange are identical if and only if all of the binding args are also identical. > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: New Defects reported by Coverity Scan for Apache-Qpid
Ok - I'll give it a go, stay tuned. -K - Original Message - > From: "Steve Huston" > To: dev@qpid.apache.org > Sent: Monday, July 1, 2013 2:32:14 PM > Subject: RE: New Defects reported by Coverity Scan for Apache-Qpid > > Yes, there is a way - I can do it, probably because I'm the admin for the > project. If you create one, I'll set it up. > > > -Original Message- > > From: Ken Giusti [mailto:kgiu...@redhat.com] > > Sent: Monday, July 01, 2013 2:11 PM > > To: dev@qpid.apache.org > > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > > > Hi Steve, > > > > I've marked that particular error as "false positive" in Coverity Connect, > > but > > from what I can tell, the "right" way to fix such lock wrapper classes is > > to > > create a "model" for those wrapper classes. There's some documentation > > here: > > > > http://scan5.coverity.com:8080/docs/en/cov_checker_ref.html#static_c_ch > > ecker_LOCK > > > > > > Is there a way to configure a model file for the coverity checker? A quick > > look > > at our project page on the coverity web site didn't seem to allow that. > > > > > > - Original Message - > > > From: "Steve Huston" > > > To: dev@qpid.apache.org > > > Sent: Monday, July 1, 2013 1:18:58 PM > > > Subject: RE: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > I agree, Ken. If anyone knows how to make Coverity stop this, please > > > let me know. Else I'll check into it. I know there are a few ways to > > > mark things as false positive. > > > > > > > -Original Message- > > > > From: Ken Giusti [mailto:kgiu...@redhat.com] > > > > Sent: Monday, July 01, 2013 1:17 PM > > > > To: Qpid Dev > > > > Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > > > Unless I'm missing something subtle, this appears to be a false > > > > positive. > > > > > > > > Coverity marked a few uses of ScopedLock with this error, but not > > > > all, which seems curious. > > > > > > > > -K > > > > > > > > > > > > - Forwarded Message - > > > > > From: scan-ad...@coverity.com > > > > > To: dev@qpid.apache.org > > > > > Sent: Sunday, June 30, 2013 5:39:43 PM > > > > > Subject: New Defects reported by Coverity Scan for Apache-Qpid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __ > > > > > > > > > __ > > > > > CID 1040637: Missing unlock (LOCK) > > > > > > > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > > > 379 ( > > > > > lock) > > > > >376 > > > > >377void Connection::doIoCallbacks() { > > > > >378if (!isOpen()) return; // Don't process IO callbacks > > > > >until > > > > >we > > > > >are open. > > > > > >>> > > > > "qpid::sys::ScopedLock::ScopedLock(qpid::sys::Mute > > > > x > > > > &)" > > > > > >>> locks "this->ioCallbackLock.mutex". > > > > >379ScopedLock l(ioCallbackLock); > > > > >380while (!ioCallbacks.empty()) { > > > > >381boost::function0 cb = ioCallbacks.front(); > > > > >382ioCallbacks.pop(); > > > > >383ScopedUnlock ul(ioCallbackLock); > > > > > > > > > > > > > > > > > /qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp: > > > > > 386 ( > > > > > missing_unlock) > > > > >383ScopedUnlock ul(ioCallbackLock); > > > > >384cb(); // Lend the IO thread for management > > > > >processing > > > > >385} > > > > > >>> CID 1040637: Missing unlock (LOCK) Returning without unlocking > > > > > >>> "this->ioCallbackLock.mutex". > > > > >386} > > > > >387 > > > > >388bool Connection::doOutput() { > > > > >389try { > > > > >390doIoCallbacks(); > > > > > > > > > > > > > > > > __ > > > > > > > > > __ To view the defects in Coverity Scan visit, > > > > > http://scan.coverity.com > > > > > > > > > > To unsubscribe from the email notification for new defects, > > > > > http://scan5.coverity.com/cgi-bin/unsubscribe.py > > > > > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For > > > > additional commands, e-mail: dev-h...@qpid.apache.org > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > > > commands, e-mail: dev-h...@qpid.apache.org > > > > > > > -- > > -K > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional > > commands, e-mail: dev-h...@qpid.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additiona