[jira] [Commented] (QPID-5073) [Java Broker] Refactor DurableConfigurationStore recovery to allow for additional configured object children other than just Exchange/Binding/Queue
[ https://issues.apache.org/jira/browse/QPID-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742069#comment-13742069 ] ASF subversion and git services commented on QPID-5073: --- Commit 1514639 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1514639 ] QPID-5073 : Add dependency on alternate exchange for queues where such an alternate is set [Java Broker] Refactor DurableConfigurationStore recovery to allow for additional configured object children other than just Exchange/Binding/Queue --- Key: QPID-5073 URL: https://issues.apache.org/jira/browse/QPID-5073 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Following on from QPID-4973, further modify the DurableConfigurationStore such that recovery is capable of handling object types other than Exchange/Queue/Binding. This requires recovery to be in two steps - a load and then a resolution phase, where resolution is the process by which dependencies between the stored configured objects are resolved. -- 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-5073) [Java Broker] Refactor DurableConfigurationStore recovery to allow for additional configured object children other than just Exchange/Binding/Queue
[ https://issues.apache.org/jira/browse/QPID-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742070#comment-13742070 ] ASF subversion and git services commented on QPID-5073: --- Commit 1514640 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1514640 ] QPID-5073 : Add dependency on alternate exchange for queues where such an alternate is set [Java Broker] Refactor DurableConfigurationStore recovery to allow for additional configured object children other than just Exchange/Binding/Queue --- Key: QPID-5073 URL: https://issues.apache.org/jira/browse/QPID-5073 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Following on from QPID-4973, further modify the DurableConfigurationStore such that recovery is capable of handling object types other than Exchange/Queue/Binding. This requires recovery to be in two steps - a load and then a resolution phase, where resolution is the process by which dependencies between the stored configured objects are resolved. -- 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-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742100#comment-13742100 ] ASF subversion and git services commented on QPID-5074: --- Commit 1514654 from [~gemmellr] in branch 'qpid/trunk' [ https://svn.apache.org/r1514654 ] QPID-5074: update broker binary release tar process to handle plugins with dependencies, fix issues with generated poms [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.24 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 Attachments: 0001-QPID-5074-update-broker-binary-release-tar-process-t.patch The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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-5050) Clients calling Connection#stop() from within an ExceptionListener have potential for deadlock
[
https://issues.apache.org/jira/browse/QPID-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742128#comment-13742128
]
ASF subversion and git services commented on QPID-5050:
---
Commit 1514664 from [~k-wall] in branch 'qpid/trunk'
[ https://svn.apache.org/r1514664 ]
QPID-5050: Move invocation of ExceptionListener to after the failoverMutex is
released avoiding deadlock possibility
Previously, the ExceptionListener was invoked whilst the failoverMutex was
held, between the
two potential state changes (connection state change and session state change).
This commit reorders the statements so that the ExceptionListner is fired after
the failoverMutex
is released. It also means that the ExceptionListener is fired *after* both
connection/session
have undergone any state changes. The exceptionListener member is also made
thread safe.
Clients calling Connection#stop() from within an ExceptionListener have
potential for deadlock
--
Key: QPID-5050
URL: https://issues.apache.org/jira/browse/QPID-5050
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22
Reporter: Keith Wall
Assignee: Keith Wall
Attachments:
0001-QPID-5050-Move-invocation-of-ExceptionListener-to-af.patch
A deadlock possibility exists for client applications calling Connection#stop
within an application owned ExceptionListener.
Unfortunately a common messaging framework (Spring), installs such a
ExceptionListener.
In a recent support call, such a deadlock had occurred between the dispatcher
thread (whose onMessage was in the process of creating a session) and a
pooled thread bouncing a message back to the application. (The bounced
messages is returned to the application via the exception listener).
The deadlock involves the Dispatcher._lock and AMQConnection._failoverMutex.
The deadlock was reproduced with a system test (attached to Jira) and
deadlock captured with jstack -l pid (output below).
{noformat}
Dispatcher-1-Conn-4 pool-8-thread-1
+ acquires c888 (Dispatcher#_lock)+ acquires ca68
(AMQConnection#_failoverMutex)
+ tries to acquire ca68 + tries to acquire c888
{noformat}
{noformat}
Found one Java-level deadlock:
=
pool-8-thread-1:
waiting to lock monitor 0x5b0d3560 (object 0xf70bc888, a
java.lang.Object),
which is held by Dispatcher-1-Conn-4
Dispatcher-1-Conn-4:
waiting to lock monitor 0x5b187308 (object 0xf70bca68, a
java.lang.Object),
which is held by pool-8-thread-1
Java stack information for the threads listed above:
===
pool-8-thread-1:
at
org.apache.qpid.client.AMQSession$Dispatcher.setConnectionStopped(AMQSession.java:3276)
- waiting to lock 0xf70bc888 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.stop(AMQSession.java:2382)
at org.apache.qpid.client.AMQConnection.stop(AMQConnection.java:835)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$4.onException(ExceptionListenerTest.java:206)
at
org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1329)
- locked 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession_0_8$4.run(AMQSession_0_8.java:600)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-4:
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.executeRetrySupport(AMQConnectionDelegate_8_0.java:333)
- waiting to lock 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at
org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at
org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2600)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1176)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:98)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$5.onMessage(ExceptionListenerTest.java:229)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at
[jira] [Updated] (QPID-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-5074: - Attachment: (was: 0001-QPID-5074-update-broker-binary-release-tar-process-t.patch) [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.24 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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
Request for inclusion in 0.24
Hi Justin, I would like to include https://issues.apache.org/jira/browse/QPID-5074into 0.24. The commit makes some updates to the handling of plugins for the java broker during the release process in order to address the problem identified below by Gordon as well as some related plugin handling issues that came to light during the change. Rob has reviewed the changes and commented on the JIRA to that effect. Robbie On 14 August 2013 17:17, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 14 August 2013 16:15, Gordon Sim g...@redhat.com wrote: snip I'm quite sure this is user error, but I was not able to connect from c++ to the Java broker using AMQP 1.0 (0-10 was fine). There is no error and it seems to reject the header (with or without SASL), as if it didn't recognise 1.0. This was enabled by default in my previous testing, do I need to do something explicit now? This is a 'bug', there is still a jar missing due to a bit of stupidity from our lovely build system, we will look to fix this for the next RC.
[jira] [Updated] (QPID-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-5074: - Affects Version/s: 0.23 [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.23, 0.24 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-5074: - Affects Version/s: (was: 0.24) [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.23 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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: RFQ 0.24: Two JIRAs
On Mon, Aug 12, 2013 at 08:52:20PM +0200, Jimmy Jones wrote: I'm a user of binary data in maps! I created the patch to handle UTF8 in perl. Removing the check will cause non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless by luck they are 7 bit ASCII. Hey, Jimmy. I've been in training this week so haven't been able to respond. I reverted my changes, and would like to collaborate with you on a better, more considered solution to the problem of sending properties from Perl and the other dynamic languages. Are you available to chat in IRC (Freenode #qpid channel) sometime? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgprCmR8_l_yv.pgp Description: PGP signature
[jira] [Resolved] (QPID-5050) Clients calling Connection#stop() from within an ExceptionListener have potential for deadlock
[
https://issues.apache.org/jira/browse/QPID-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-5050.
--
Resolution: Fixed
Fix Version/s: 0.25
Phil's review comments are addressed and patch applied.
Clients calling Connection#stop() from within an ExceptionListener have
potential for deadlock
--
Key: QPID-5050
URL: https://issues.apache.org/jira/browse/QPID-5050
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.25
Attachments:
0001-QPID-5050-Move-invocation-of-ExceptionListener-to-af.patch
A deadlock possibility exists for client applications calling Connection#stop
within an application owned ExceptionListener.
Unfortunately a common messaging framework (Spring), installs such a
ExceptionListener.
In a recent support call, such a deadlock had occurred between the dispatcher
thread (whose onMessage was in the process of creating a session) and a
pooled thread bouncing a message back to the application. (The bounced
messages is returned to the application via the exception listener).
The deadlock involves the Dispatcher._lock and AMQConnection._failoverMutex.
The deadlock was reproduced with a system test (attached to Jira) and
deadlock captured with jstack -l pid (output below).
{noformat}
Dispatcher-1-Conn-4 pool-8-thread-1
+ acquires c888 (Dispatcher#_lock)+ acquires ca68
(AMQConnection#_failoverMutex)
+ tries to acquire ca68 + tries to acquire c888
{noformat}
{noformat}
Found one Java-level deadlock:
=
pool-8-thread-1:
waiting to lock monitor 0x5b0d3560 (object 0xf70bc888, a
java.lang.Object),
which is held by Dispatcher-1-Conn-4
Dispatcher-1-Conn-4:
waiting to lock monitor 0x5b187308 (object 0xf70bca68, a
java.lang.Object),
which is held by pool-8-thread-1
Java stack information for the threads listed above:
===
pool-8-thread-1:
at
org.apache.qpid.client.AMQSession$Dispatcher.setConnectionStopped(AMQSession.java:3276)
- waiting to lock 0xf70bc888 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.stop(AMQSession.java:2382)
at org.apache.qpid.client.AMQConnection.stop(AMQConnection.java:835)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$4.onException(ExceptionListenerTest.java:206)
at
org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1329)
- locked 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession_0_8$4.run(AMQSession_0_8.java:600)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-4:
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.executeRetrySupport(AMQConnectionDelegate_8_0.java:333)
- waiting to lock 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at
org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at
org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2600)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1176)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:98)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$5.onMessage(ExceptionListenerTest.java:229)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
- locked 0xf71747e0 (a java.lang.Object)
- locked 0xf70bc888 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3250)
[jira] [Updated] (QPID-5050) Clients calling Connection#stop() (or #close()) from within an ExceptionListener have potential for deadlock
[
https://issues.apache.org/jira/browse/QPID-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-5050:
-
Summary: Clients calling Connection#stop() (or #close()) from within an
ExceptionListener have potential for deadlock (was: Clients calling
Connection#stop() from within an ExceptionListener have potential for deadlock)
Clients calling Connection#stop() (or #close()) from within an
ExceptionListener have potential for deadlock
Key: QPID-5050
URL: https://issues.apache.org/jira/browse/QPID-5050
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.25
Attachments:
0001-QPID-5050-Move-invocation-of-ExceptionListener-to-af.patch
A deadlock possibility exists for client applications calling Connection#stop
within an application owned ExceptionListener.
Unfortunately a common messaging framework (Spring), installs such a
ExceptionListener.
In a recent support call, such a deadlock had occurred between the dispatcher
thread (whose onMessage was in the process of creating a session) and a
pooled thread bouncing a message back to the application. (The bounced
messages is returned to the application via the exception listener).
The deadlock involves the Dispatcher._lock and AMQConnection._failoverMutex.
The deadlock was reproduced with a system test (attached to Jira) and
deadlock captured with jstack -l pid (output below).
{noformat}
Dispatcher-1-Conn-4 pool-8-thread-1
+ acquires c888 (Dispatcher#_lock)+ acquires ca68
(AMQConnection#_failoverMutex)
+ tries to acquire ca68 + tries to acquire c888
{noformat}
{noformat}
Found one Java-level deadlock:
=
pool-8-thread-1:
waiting to lock monitor 0x5b0d3560 (object 0xf70bc888, a
java.lang.Object),
which is held by Dispatcher-1-Conn-4
Dispatcher-1-Conn-4:
waiting to lock monitor 0x5b187308 (object 0xf70bca68, a
java.lang.Object),
which is held by pool-8-thread-1
Java stack information for the threads listed above:
===
pool-8-thread-1:
at
org.apache.qpid.client.AMQSession$Dispatcher.setConnectionStopped(AMQSession.java:3276)
- waiting to lock 0xf70bc888 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.stop(AMQSession.java:2382)
at org.apache.qpid.client.AMQConnection.stop(AMQConnection.java:835)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$4.onException(ExceptionListenerTest.java:206)
at
org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1329)
- locked 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession_0_8$4.run(AMQSession_0_8.java:600)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-4:
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.executeRetrySupport(AMQConnectionDelegate_8_0.java:333)
- waiting to lock 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at
org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at
org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2600)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1176)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:98)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$5.onMessage(ExceptionListenerTest.java:229)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
- locked 0xf71747e0 (a java.lang.Object)
- locked 0xf70bc888 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
at
Re: RFQ 0.24: Two JIRAs
On 08/16/2013 01:15 PM, Darryl L. Pierce wrote: On Mon, Aug 12, 2013 at 08:52:20PM +0200, Jimmy Jones wrote: I'm a user of binary data in maps! I created the patch to handle UTF8 in perl. Removing the check will cause non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless by luck they are 7 bit ASCII. Hey, Jimmy. I've been in training this week so haven't been able to respond. I reverted my changes, and would like to collaborate with you on a better, more considered solution to the problem of sending properties from Perl and the other dynamic languages. For Perl, what was wrong with the original code (as it is now you have reverted your changes)? It looks like that allows one to explicitly pass utf8 strings that will then be encoded as such. Whats the problem statement? For python, might one solution be to encode unicode strings as utf8? Again that at least gives you the ability to control what happens. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742188#comment-13742188 ] Justin Ross commented on QPID-5074: --- Reviewed by Rob. Approved for 0.24. [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.23 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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] [Comment Edited] (QPID-5074) [Java Broker] update broker binary release tar process to handle plugins with dependencies
[ https://issues.apache.org/jira/browse/QPID-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742188#comment-13742188 ] Justin Ross edited comment on QPID-5074 at 8/16/13 1:13 PM: Reviewed by Rob. Approved for 0.24. http://qpid.2158936.n2.nabble.com/Request-for-inclusion-in-0-24-tt7597021.html was (Author: justi9): Reviewed by Rob. Approved for 0.24. [Java Broker] update broker binary release tar process to handle plugins with dependencies -- Key: QPID-5074 URL: https://issues.apache.org/jira/browse/QPID-5074 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.23 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Blocker Fix For: 0.24 The process used to create the broker binary release has historically lacked awareness of plugin dependencies, because none of them had any that we distribute. As more functionality has been made pluggable during the 0.24 development cycle, we now have plugins with dependencies we need to take into account and the process must be updated accordingly. -- 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: RFQ 0.24: Two JIRAs
For python, this is indeed the solution we used when a user wanted the Java client to recognize a python string sent in a map or an application property. On Fri, Aug 16, 2013 at 8:55 AM, Gordon Sim g...@redhat.com wrote: On 08/16/2013 01:15 PM, Darryl L. Pierce wrote: On Mon, Aug 12, 2013 at 08:52:20PM +0200, Jimmy Jones wrote: I'm a user of binary data in maps! I created the patch to handle UTF8 in perl. Removing the check will cause non-UTF8 strings to be casted into UTF8 which is probably a bad idea unless by luck they are 7 bit ASCII. Hey, Jimmy. I've been in training this week so haven't been able to respond. I reverted my changes, and would like to collaborate with you on a better, more considered solution to the problem of sending properties from Perl and the other dynamic languages. For Perl, what was wrong with the original code (as it is now you have reverted your changes)? It looks like that allows one to explicitly pass utf8 strings that will then be encoded as such. Whats the problem statement? For python, might one solution be to encode unicode strings as utf8? Again that at least gives you the ability to control what happens. --**--**- To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**orgdev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5078) consumers not notified of messages if another consumer with selector/filter doesn't want it
Gordon Sim created QPID-5078:
Summary: consumers not notified of messages if another consumer
with selector/filter doesn't want it
Key: QPID-5078
URL: https://issues.apache.org/jira/browse/QPID-5078
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.24
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.25
E.g. run
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
and in another terminal:
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
then:
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
--
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-5078) consumers not notified of messages if another consumer with selector/filter doesn't want it
[
https://issues.apache.org/jira/browse/QPID-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-5078:
-
Description:
E.g. run
{noformat}
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
{noformat}
and in another terminal:
{noformat}
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
{noformat}
then:
{noformat}
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
{noformat}
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
was:
E.g. run
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
and in another terminal:
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
then:
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
consumers not notified of messages if another consumer with selector/filter
doesn't want it
---
Key: QPID-5078
URL: https://issues.apache.org/jira/browse/QPID-5078
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.24
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.25
E.g. run
{noformat}
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
{noformat}
and in another terminal:
{noformat}
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
{noformat}
then:
{noformat}
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
{noformat}
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
--
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
Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
[jira] [Commented] (QPID-5078) consumers not notified of messages if another consumer with selector/filter doesn't want it
[
https://issues.apache.org/jira/browse/QPID-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742402#comment-13742402
]
Gordon Sim commented on QPID-5078:
--
See https://reviews.apache.org/r/13619/ for suggested fix
consumers not notified of messages if another consumer with selector/filter
doesn't want it
---
Key: QPID-5078
URL: https://issues.apache.org/jira/browse/QPID-5078
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.24
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.25
E.g. run
{noformat}
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
{noformat}
and in another terminal:
{noformat}
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
{noformat}
then:
{noformat}
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
{noformat}
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
--
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 13619: ensure notifications to queue listeners works when using selectors/filters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/#review25238 --- /trunk/qpid/cpp/src/qpid/broker/Queue.cpp https://reviews.apache.org/r/13619/#comment49533 Do you need both set and notifyRequired? It looks like set is only non-empty if notifyRequired (but I may have missed a case). - Andrew Stitcher On Aug. 16, 2013, 5:09 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 5:09 p.m.) Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
Re: Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
On Aug. 16, 2013, 6:13 p.m., Andrew Stitcher wrote: /trunk/qpid/cpp/src/qpid/broker/Queue.cpp, line 447 https://reviews.apache.org/r/13619/diff/1/?file=342087#file342087line447 Do you need both set and notifyRequired? It looks like set is only non-empty if notifyRequired (but I may have missed a case). There is no way to test the set however. Now an alternative fix would of course be to add such a method and use that. This approach seemed reasonable to me. - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/#review25238 --- On Aug. 16, 2013, 5:09 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 5:09 p.m.) Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
Re: Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
On Aug. 16, 2013, 6:13 p.m., Andrew Stitcher wrote: /trunk/qpid/cpp/src/qpid/broker/Queue.cpp, line 447 https://reviews.apache.org/r/13619/diff/1/?file=342087#file342087line447 Do you need both set and notifyRequired? It looks like set is only non-empty if notifyRequired (but I may have missed a case). Gordon Sim wrote: There is no way to test the set however. Now an alternative fix would of course be to add such a method and use that. This approach seemed reasonable to me. It occurs to me that I may have misunderstood your point. Are you saying that the conditional notify() is not needed, since it is a no-op if the set is not populated? That would in fact be the case and would make the change simpler. - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/#review25238 --- On Aug. 16, 2013, 5:09 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 5:09 p.m.) Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
Re: Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 7:48 p.m.) Review request for qpid and Andrew Stitcher. Changes --- Remove unnecessary notifyRequired flag, as suggested by Andrew (I think!). Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs (updated) - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
Re: Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
On Aug. 16, 2013, 6:13 p.m., Andrew Stitcher wrote: /trunk/qpid/cpp/src/qpid/broker/Queue.cpp, line 447 https://reviews.apache.org/r/13619/diff/1/?file=342087#file342087line447 Do you need both set and notifyRequired? It looks like set is only non-empty if notifyRequired (but I may have missed a case). Gordon Sim wrote: There is no way to test the set however. Now an alternative fix would of course be to add such a method and use that. This approach seemed reasonable to me. Gordon Sim wrote: It occurs to me that I may have misunderstood your point. Are you saying that the conditional notify() is not needed, since it is a no-op if the set is not populated? That would in fact be the case and would make the change simpler. Yes that was one of my thoughts, sorry for being obtuse. - Andrew --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/#review25238 --- On Aug. 16, 2013, 7:48 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 7:48 p.m.) Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
Re: Review Request 13619: ensure notifications to queue listeners works when using selectors/filters
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/#review25255 --- Ship it! Ship It! - Andrew Stitcher On Aug. 16, 2013, 7:48 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13619/ --- (Updated Aug. 16, 2013, 7:48 p.m.) Review request for qpid and Andrew Stitcher. Bugs: QPID-5078 https://issues.apache.org/jira/browse/QPID-5078 Repository: qpid Description --- This change ensures that if a consumer with a filter/selector skips over a message, then other listeners or consumers will still get notified of the availability of that skipped message. Diffs - /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1514329 Diff: https://reviews.apache.org/r/13619/diff/ Testing --- make test passes Thanks, Gordon Sim
[jira] [Created] (QPID-5079) Only export necessary symbols from the supported client API libraries
Andrew Stitcher created QPID-5079: - Summary: Only export necessary symbols from the supported client API libraries Key: QPID-5079 URL: https://issues.apache.org/jira/browse/QPID-5079 Project: Qpid Issue Type: Improvement Components: C++ Client Environment: Linux Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- 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-5078) consumers not notified of messages if another consumer with selector/filter doesn't want it
[
https://issues.apache.org/jira/browse/QPID-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742650#comment-13742650
]
ASF subversion and git services commented on QPID-5078:
---
Commit 1514907 from [~gsim] in branch 'qpid/trunk'
[ https://svn.apache.org/r1514907 ]
QPID-5078: ensure listeners are always notified if a message was left on the
queue
consumers not notified of messages if another consumer with selector/filter
doesn't want it
---
Key: QPID-5078
URL: https://issues.apache.org/jira/browse/QPID-5078
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.24
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.25
E.g. run
{noformat}
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
{noformat}
and in another terminal:
{noformat}
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
{noformat}
then:
{noformat}
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
{noformat}
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
--
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] [Resolved] (QPID-5078) consumers not notified of messages if another consumer with selector/filter doesn't want it
[
https://issues.apache.org/jira/browse/QPID-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-5078.
--
Resolution: Fixed
consumers not notified of messages if another consumer with selector/filter
doesn't want it
---
Key: QPID-5078
URL: https://issues.apache.org/jira/browse/QPID-5078
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.24
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.25
E.g. run
{noformat}
drain q; {create:always, link:{selector:\colour = 'red'\}} -f
{noformat}
and in another terminal:
{noformat}
drain q; {create:always, link:{selector:\colour = 'blue'\}} -f
{noformat}
then:
{noformat}
for i in `seq 1 5`; do spout --content red-$i -P colour=red q; done
for i in `seq 1 5`; do spout --content blue-$i -P colour=blue q; done
for i in `seq 6 10`; do spout --content red-$i -P colour=red q; done
{noformat}
Expect first drain to see all 10 'red' messages, second drain to see all 5
'blue' messages but in practice this doesn't (always) happen. The message are
on the queue but the consumers are not always notified of their existence.
--
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
