[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-tabpanelfocusedCommentId=13697599#comment-13697599
]
Gordon Sim commented on QPID-4969:
--
Ah... no wonder it didn't work then. Odd as I have the ! in my local copy.
Anyway... looks good as committed.
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-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-tabpanelfocusedCommentId=13697678#comment-13697678 ] Rob Godfrey commented on QPID-4943: --- The tests were not being excluded from the C++ profile, and were thus causing the Jenkins job to fail. I have added them to the relevant exclude list [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] [Created] (QPID-4972) Dead link on web page
Earl Harris Jr. created QPID-4972: - Summary: Dead link on web page Key: QPID-4972 URL: https://issues.apache.org/jira/browse/QPID-4972 Project: Qpid Issue Type: Improvement Components: Website Environment: Windows 7, Dell laptop Reporter: Earl Harris Jr. Priority: Minor On the page http://qpid.apache.org/getting_started.html running a Qpid Java broker (AMQP 0-8, 0-9) (a.k.a https://cwiki.apache.org/qpid/getting-started-guide.html) is a dead link. Not Found The requested URL /qpid/getting-started-guide.html was not found on this server. Apache/2.2.22 (Ubuntu) Server at cwiki.apache.org Port 80 I'd like to read the actual page, BTW. -- 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: C++ broker class: ExpiryPolicy
On 06/28/2013 05:23 PM, Andrew Stitcher wrote: Alan et al, The C++ broker class qpid::broker::ExpiryPolicy looks like another leftover piece of the old clustering code which could be completely folded into the qpid::broker::Message code. Is this is correct assertion? Yes, and in fact I think it can simply be deleted rather than folded. Nothing is using that interface anymore. - 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 made a minor code change that seems to eliminate those locking false
positives:
http://svn.apache.org/viewvc?view=revisionrevision=1498926
I've tried it against a local installation of Coverity. When you have a
chance, can you kick off a coverity scan of upstream and see if we get the same
results? If it eliminates the false positives, I'd consider Coverity's
behavior buggy and would like to report it.
BTW, I had no luck coming up with a model that would fix the issue. The tools
don't give any (obvious) feedback as to how it's interpreting the model - or
any way that I could find that would enable debugging of the model to find out
what it was actually doing.
-K
- Original Message -
From: Ken Giusti kgiu...@redhat.com
To: dev@qpid.apache.org
Cc: shus...@riverace.com
Sent: Monday, July 1, 2013 6:46:55 PM
Subject: 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 shus...@riverace.com
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 shus...@riverace.com
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::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mute
x
)
locks this-ioCallbackLock.mutex.
379ScopedLockMutex l(ioCallbackLock);
380while (!ioCallbacks.empty()) {
381boost::function0void cb = ioCallbacks.front();
382ioCallbacks.pop();
383ScopedUnlockMutex ul(ioCallbackLock);
/qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp:
386 (
missing_unlock)
383ScopedUnlockMutex 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
Re: New Defects reported by Coverity Scan for Apache-Qpid
As an aside, I notice that they seem to have enabled scanning of Java
projects as well as C++ now... we should maybe look to see what a coverity
scan of the Java code looks like
-- Rob
On 2 July 2013 16:16, Ken Giusti kgiu...@redhat.com wrote:
Hi Steve,
I've made a minor code change that seems to eliminate those locking false
positives:
http://svn.apache.org/viewvc?view=revisionrevision=1498926
I've tried it against a local installation of Coverity. When you have a
chance, can you kick off a coverity scan of upstream and see if we get the
same results? If it eliminates the false positives, I'd consider
Coverity's behavior buggy and would like to report it.
BTW, I had no luck coming up with a model that would fix the issue. The
tools don't give any (obvious) feedback as to how it's interpreting the
model - or any way that I could find that would enable debugging of the
model to find out what it was actually doing.
-K
- Original Message -
From: Ken Giusti kgiu...@redhat.com
To: dev@qpid.apache.org
Cc: shus...@riverace.com
Sent: Monday, July 1, 2013 6:46:55 PM
Subject: 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 shus...@riverace.com
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 shus...@riverace.com
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::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mute
x
)
locks this-ioCallbackLock.mutex.
379ScopedLockMutex l(ioCallbackLock);
380while (!ioCallbacks.empty()) {
381boost::function0void cb =
ioCallbacks.front();
382ioCallbacks.pop();
383ScopedUnlockMutex ul(ioCallbackLock);
/qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp:
386 (
missing_unlock)
383ScopedUnlockMutex 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();
__
RE: New Defects reported by Coverity Scan for Apache-Qpid
Yes, I noticed that too - and Coverity was fairly eager to get a scan of the
Qpid Java code back when we started, but they weren't ready to scan Java quite
yet.
If anyone would like to tackle the Java scans, and is not yet signed up at
coverity.com, please let me know and I'll help get you going.
From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
Sent: Tuesday, July 02, 2013 10:41 AM
To: qpid
Cc: Steve Huston
Subject: Re: New Defects reported by Coverity Scan for Apache-Qpid
As an aside, I notice that they seem to have enabled scanning of Java projects
as well as C++ now... we should maybe look to see what a coverity scan of the
Java code looks like
-- Rob
On 2 July 2013 16:16, Ken Giusti
kgiu...@redhat.commailto:kgiu...@redhat.com wrote:
Hi Steve,
I've made a minor code change that seems to eliminate those locking false
positives:
http://svn.apache.org/viewvc?view=revisionrevision=1498926
I've tried it against a local installation of Coverity. When you have a
chance, can you kick off a coverity scan of upstream and see if we get the same
results? If it eliminates the false positives, I'd consider Coverity's
behavior buggy and would like to report it.
BTW, I had no luck coming up with a model that would fix the issue. The tools
don't give any (obvious) feedback as to how it's interpreting the model - or
any way that I could find that would enable debugging of the model to find out
what it was actually doing.
-K
- Original Message -
From: Ken Giusti kgiu...@redhat.commailto:kgiu...@redhat.com
To: dev@qpid.apache.orgmailto:dev@qpid.apache.org
Cc: shus...@riverace.commailto:shus...@riverace.com
Sent: Monday, July 1, 2013 6:46:55 PM
Subject: 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 shus...@riverace.commailto:shus...@riverace.com
To: dev@qpid.apache.orgmailto: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.commailto:kgiu...@redhat.com]
Sent: Monday, July 01, 2013 2:11 PM
To: dev@qpid.apache.orgmailto: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 shus...@riverace.commailto:shus...@riverace.com
To: dev@qpid.apache.orgmailto: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.commailto: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.commailto:scan-ad...@coverity.com
To: dev@qpid.apache.orgmailto: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::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mute
x
)
locks this-ioCallbackLock.mutex.
379ScopedLockMutex l(ioCallbackLock);
380while (!ioCallbacks.empty()) {
381boost::function0void cb = ioCallbacks.front();
382ioCallbacks.pop();
[jira] [Updated] (QPID-4973) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes
[ https://issues.apache.org/jira/browse/QPID-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-4973: -- Issue Type: Improvement (was: Bug) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes Key: QPID-4973 URL: https://issues.apache.org/jira/browse/QPID-4973 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey -- 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-4973) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes
Rob Godfrey created QPID-4973: - Summary: [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes Key: QPID-4973 URL: https://issues.apache.org/jira/browse/QPID-4973 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey -- 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] [Updated] (QPID-4973) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes
[ https://issues.apache.org/jira/browse/QPID-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-4973: -- Description: As part of the ongoing changes to the Java Broker configuration model, make the DurableConfigurationStore (essentially the config store for a vhost) expose only a generic interface for configured objects, and not restrict to concrete implementation classes such as Queue, Exchange, Binding, etc. (Note that the representation of the objects in the BDB and JDBC/Derby stores is already in a generic form. [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes Key: QPID-4973 URL: https://issues.apache.org/jira/browse/QPID-4973 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey As part of the ongoing changes to the Java Broker configuration model, make the DurableConfigurationStore (essentially the config store for a vhost) expose only a generic interface for configured objects, and not restrict to concrete implementation classes such as Queue, Exchange, Binding, etc. (Note that the representation of the objects in the BDB and JDBC/Derby stores is already in a generic form. -- 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-4973) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes
[ https://issues.apache.org/jira/browse/QPID-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697883#comment-13697883 ] ASF subversion and git services commented on QPID-4973: --- Commit 1498976 from [~godfrer] [ https://svn.apache.org/r1498976 ] QPID-4973 : [Java Broker] Refactor DurableConfigurationStore [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes Key: QPID-4973 URL: https://issues.apache.org/jira/browse/QPID-4973 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey As part of the ongoing changes to the Java Broker configuration model, make the DurableConfigurationStore (essentially the config store for a vhost) expose only a generic interface for configured objects, and not restrict to concrete implementation classes such as Queue, Exchange, Binding, etc. (Note that the representation of the objects in the BDB and JDBC/Derby stores is already in a generic form. -- 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] [Updated] (QPID-4619) memory leak in C++ broker resulting in out of memory
[ https://issues.apache.org/jira/browse/QPID-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sun updated QPID-4619: -- Description: Start C++ Cluster including two nodes, send messages to one node, and recv messages from other node in keep-alive connection, then finally throw out of memory after a few days.To reproduce the problem, a simple program included in attachs. 1. mkdir -p /root/sun/sendFile. Copy some test files to the dir and the files' content will be send to Broker as messages. 2. modify cluster node's ip address in memoryTest/sendFile/testSend.sh included in attaches. 3. sh testSend.sh 4. modify cluster other node's ip address in memoryTest/recvFile/crazy.sh. 5. excute the script-memoryTest/recvFile/testRecv.sh. The steps will reproduce the problem. Start one C++ Broker not as cluster node, and do test as the description will also reproduce the bug. was: Start C++ Cluster including two nodes, send messages to one node, and recv messages from other node in keep-alive connection, then finally throw out of memory after a few days.To reproduce the problem, a simple program included in attachs. 1. mkdir -p /root/sun/sendFile. Copy some test files to the dir and the files' content will be send to Broker as messages. 2. modify cluster node's ip address in memoryTest/sendFile/testSend.sh included in attaches. 3. sh testSend.sh 4. modify cluster other node's ip address in memoryTest/recvFile/crazy.sh. 5. excute the script-memoryTest/recvFile/testRecv.sh. The steps will reproduce the problem. Start one C++ Broker not as cluster node, and do test as the description will also reproduce the bug. I'm sorry I can't get core file because broker's memroy too large memory leak in C++ broker resulting in out of memory Key: QPID-4619 URL: https://issues.apache.org/jira/browse/QPID-4619 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Environment: RedHat6.1 Reporter: sun Assignee: Alan Conway Attachments: memoryTest.tar.gz Start C++ Cluster including two nodes, send messages to one node, and recv messages from other node in keep-alive connection, then finally throw out of memory after a few days.To reproduce the problem, a simple program included in attachs. 1. mkdir -p /root/sun/sendFile. Copy some test files to the dir and the files' content will be send to Broker as messages. 2. modify cluster node's ip address in memoryTest/sendFile/testSend.sh included in attaches. 3. sh testSend.sh 4. modify cluster other node's ip address in memoryTest/recvFile/crazy.sh. 5. excute the script-memoryTest/recvFile/testRecv.sh. The steps will reproduce the problem. Start one C++ Broker not as cluster node, and do test as the description will also reproduce the bug. -- 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-4973) [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes
[ https://issues.apache.org/jira/browse/QPID-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697886#comment-13697886 ] Rob Godfrey commented on QPID-4973: --- First commit exposes the API as a tuple of id, type, attributes and moves the conversion from the implementation objects into DurableConfigurationStoreHelper. Outstanding steps are: 1. Use simple name (e.g. Queue) rather than full class names for types (cf broker json store) 2. move creation/removal logic into a central location 3. allow for saving of additional attributes, and reconcile model names and queue creation names for the attributes [Java Broker] Refactor DurableConfigurationStore interface to be in terms of ConfiguredObject rather than implementation classes Key: QPID-4973 URL: https://issues.apache.org/jira/browse/QPID-4973 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey As part of the ongoing changes to the Java Broker configuration model, make the DurableConfigurationStore (essentially the config store for a vhost) expose only a generic interface for configured objects, and not restrict to concrete implementation classes such as Queue, Exchange, Binding, etc. (Note that the representation of the objects in the BDB and JDBC/Derby stores is already in a generic form. -- 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: Website update 6
On Thu, Jun 20, 2013 at 10:13 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I gave it another look in IE8 and the site now renders, though it does so with an error indicated and much of the styling for headings, navigation highlighting, column layouts, fonts etc doesn't seem to be as intended. I've fixed the javascript error. My testing (on IE8 on XP) shows the layout and styling working properly, with the exception of things that only newer browsers support, such as font loading and rounded borders. It's usable in a pinch but can be quite hard to follow, particularly for the documentation etc. I also spent time moving around in the documentation in IE8, and for me it seems to be working well. I also just noticed that the search image in the top right and the Apache feather image in the footer navigation gets a blue border in IE (8 and 10, which seems to otherwise match Firefox 21). This is fixed. Thanks, Justin - 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-tabpanelfocusedCommentId=13698035#comment-13698035
]
Fraser Adams commented on QPID-4969:
Thanks guys, I've just rebuilt off trunk on r1499027 and all seems to be well
with my little test case again, yay!!!
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: Review Request 12165: QPID-4328: HA support for transactions initial design doc.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12165/ --- (Updated July 2, 2013, 6:02 p.m.) Review request for qpid, Gordon Sim, Kenneth Giusti, and Weston Price. Changes --- Added Weston to review list. Repository: qpid Description --- QPID-4328: HA support for transactions initial design doc. This is a sketch of the design for HA transactions. There are still a couple of areas that I'm not satisfied with. Any comments much appreciated. Diffs - /trunk/qpid/cpp/design_docs/ha-transactions.md PRE-CREATION Diff: https://reviews.apache.org/r/12165/diff/ Testing --- Thanks, Alan Conway
Re: [VOTE] Remove autotools build for C++ build
On 06/27/2013 12:40 AM, Andrew Stitcher wrote: [XXX] * 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: - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Can we remove cluster tools?
On 06/28/2013 10:09 AM, Andrew Stitcher wrote: On Fri, 2013-06-28 at 06:41 -0400, Michael Goulish wrote: We still have a couple of cluster-related python tools on trunk, although there hasn't been any cluster *code* on trunk for some time. They are: ./qpid/tools/src/py/qpid-cluster-store ./qpid/tools/src/py/qpid-cluster Is there any reason they should stay ? In fact, now that I have unleashed the awesome power of find, I also see: ./qpid/cpp/src/tests/qpid-cluster-benchmark ./qpid/cpp/src/tests/cluster_test_scripts (directory, empty) ./qpid/cpp/src/tests/qpid-cluster-lag.py ./qpid/tools/src/ruby/qpid_management/lib/qpid_management/cluster.rb and, of course, ./qpid/cpp/src/qpid/cluster (directory, empty) Should we remove all these things from trunk, and recycle their bytes to create the new and better code of the future? Go for it! (All extra useless stuff is just clutter adding to the cognitive load) +1 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Website update 7
http://people.apache.org/~jross/transom/2013-07-02/ Previous versions: Update 6: http://people.apache.org/~jross/transom/2013-06-17/ http://qpid.2158936.n2.nabble.com/Website-update-6-tp7594214.html Update 5: http://people.apache.org/~jross/transom/2013-05-24/ http://qpid.2158936.n2.nabble.com/Website-update-5-td7593440.html Update 4: http://people.apache.org/~jross/transom/2013-05-10/ http://qpid.2158936.n2.nabble.com/Website-update-4-tt7592756.html Update 3: http://people.apache.org/~jross/transom/2013-04-16/ http://qpid.2158936.n2.nabble.com/Website-update-3-tt7591573.html Update 2: http://people.apache.org/~jross/transom/2013-04-03/ http://qpid.2158936.n2.nabble.com/Website-update-2-tt7591046.html Update 1: http://people.apache.org/~jross/transom/2013-03-26/ http://qpid.2158936.n2.nabble.com/Website-update-tt7590444.html Head version: http://people.apache.org/~jross/transom/head/ Changes: - Removed some links to stale wiki content (pages that haven't seen updates for more than two years) - Converted wiki links to go directly to confluence - Patched javadoc for the recent frame injection vulnerability - Added Debian package install instructions (Thanks, Ken!) - Checked links and corrected broken ones - Updated docs to final 0.22 versions - Conditionalized javascript for older browsers - Removed image border on older versions of IE - Removed XML declaration to improve browser compatibility Thanks! Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Only export C++ header files for supported APIs
On 06/27/2013 01:10 AM, Andrew Stitcher wrote: So, the call to vote: [X] * 0.24 release note as above * Notice to user list as above * Apply the change in [1] to the trunk of the tree after 0.25 has opened. [ ] Not a good idea, because we're doing/we know someone who is doing ... and they won't be able to do ... any more and this is why ... - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Only export C++ header files for supported APIs
[X] * 0.24 release note as above Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4974) Dispatch - Improve the API for parsing and composing AMQP-typed fields
[ https://issues.apache.org/jira/browse/QPID-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698243#comment-13698243 ] ASF subversion and git services commented on QPID-4974: --- Commit 1499115 from [~tedross] [ https://svn.apache.org/r1499115 ] QPID-4974 - Generalized the mechanisms for composing and parsing AMQP-encoded fields. Dispatch - Improve the API for parsing and composing AMQP-typed fields -- Key: QPID-4974 URL: https://issues.apache.org/jira/browse/QPID-4974 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross Assignee: Ted Ross Dispatch needs efficient, buffer-friendly facilities for composing and parsing AMQP-encoded fields. -- 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] [Updated] (QPID-4975) AMQP 0_10 Messaging client sends empty correlation id even if no correlation Id is set
[ https://issues.apache.org/jira/browse/QPID-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4975: -- Assignee: Andrew Stitcher AMQP 0_10 Messaging client sends empty correlation id even if no correlation Id is set -- Key: QPID-4975 URL: https://issues.apache.org/jira/browse/QPID-4975 Project: Qpid Issue Type: Bug Components: C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher The qpid::messaging library holds no flag to say whether the correlation id has been set or not so when it converts the message properties to the amqp 0_10 it unconditionally sends if the user set no correlation id. It would be better if it detected an empty correlation id property and didn't send a correlation id on the wire. -- 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-4975) AMQP 0_10 Messaging client sends empty correlation id even if no correlation Id is set
Andrew Stitcher created QPID-4975: - Summary: AMQP 0_10 Messaging client sends empty correlation id even if no correlation Id is set Key: QPID-4975 URL: https://issues.apache.org/jira/browse/QPID-4975 Project: Qpid Issue Type: Bug Components: C++ Client Reporter: Andrew Stitcher The qpid::messaging library holds no flag to say whether the correlation id has been set or not so when it converts the message properties to the amqp 0_10 it unconditionally sends if the user set no correlation id. It would be better if it detected an empty correlation id property and didn't send a correlation id on the wire. -- 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-4974) Dispatch - Improve the API for parsing and composing AMQP-typed fields
[ https://issues.apache.org/jira/browse/QPID-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698329#comment-13698329 ] ASF subversion and git services commented on QPID-4974: --- Commit 1499133 from [~tedross] [ https://svn.apache.org/r1499133 ] QPID-4974 - Added parsing tests (and fixes for bugs they found). Dispatch - Improve the API for parsing and composing AMQP-typed fields -- Key: QPID-4974 URL: https://issues.apache.org/jira/browse/QPID-4974 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross Assignee: Ted Ross Dispatch needs efficient, buffer-friendly facilities for composing and parsing AMQP-encoded fields. -- 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
Thanks, Ken! It's running now - we'll see how it looks tomorrow.
On 7/2/13 10:16 AM, Ken Giusti kgiu...@redhat.com wrote:
Hi Steve,
I've made a minor code change that seems to eliminate those locking false
positives:
http://svn.apache.org/viewvc?view=revisionrevision=1498926
I've tried it against a local installation of Coverity. When you have a
chance, can you kick off a coverity scan of upstream and see if we get
the same results? If it eliminates the false positives, I'd consider
Coverity's behavior buggy and would like to report it.
BTW, I had no luck coming up with a model that would fix the issue. The
tools don't give any (obvious) feedback as to how it's interpreting the
model - or any way that I could find that would enable debugging of the
model to find out what it was actually doing.
-K
- Original Message -
From: Ken Giusti kgiu...@redhat.com
To: dev@qpid.apache.org
Cc: shus...@riverace.com
Sent: Monday, July 1, 2013 6:46:55 PM
Subject: 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 shus...@riverace.com
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 shus...@riverace.com
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::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mute
x
)
locks this-ioCallbackLock.mutex.
379ScopedLockMutex l(ioCallbackLock);
380while (!ioCallbacks.empty()) {
381boost::function0void cb =
ioCallbacks.front();
382ioCallbacks.pop();
383ScopedUnlockMutex ul(ioCallbackLock);
/qpidbuilds/trunk/qpid/cpp/src/qpid/broker/amqp_0_10/Connection.cpp:
386 (
missing_unlock)
383ScopedUnlockMutex 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
