[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
