[jira] [Commented] (QPID-4667) Selective message acknowledgement does not work over AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615112#comment-13615112 ] Justin Ross commented on QPID-4667: --- Approved for 0.22. Selective message acknowledgement does not work over AMQP 1.0 - Key: QPID-4667 URL: https://issues.apache.org/jira/browse/QPID-4667 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.20 Reporter: Gordon Sim Assignee: Gordon Sim I.e using Session::acknowledge(Message) or Session::acknowledgeUpTo(Message) rather than simply Session::acknowledge(). -- 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-4668) Message::getRedelivered() always returns true for messages received over AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615113#comment-13615113 ] Justin Ross commented on QPID-4668: --- Approved for 0.22. Message::getRedelivered() always returns true for messages received over AMQP 1.0 - Key: QPID-4668 URL: https://issues.apache.org/jira/browse/QPID-4668 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.20 Reporter: Gordon Sim Assignee: Gordon Sim regardless of whether they have been previously redelivered or not. -- 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-4667) Selective message acknowledgement does not work over AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615155#comment-13615155 ] Gordon Sim commented on QPID-4667: -- Merged to 0.22: http://svn.apache.org/r1461536 Selective message acknowledgement does not work over AMQP 1.0 - Key: QPID-4667 URL: https://issues.apache.org/jira/browse/QPID-4667 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.20 Reporter: Gordon Sim Assignee: Gordon Sim I.e using Session::acknowledge(Message) or Session::acknowledgeUpTo(Message) rather than simply Session::acknowledge(). -- 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-4667) Selective message acknowledgement does not work over AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-4667. -- Resolution: Fixed Fix Version/s: 0.21 Selective message acknowledgement does not work over AMQP 1.0 - Key: QPID-4667 URL: https://issues.apache.org/jira/browse/QPID-4667 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.20 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.21 I.e using Session::acknowledge(Message) or Session::acknowledgeUpTo(Message) rather than simply Session::acknowledge(). -- 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-4668) Message::getRedelivered() always returns true for messages received over AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-4668. -- Resolution: Fixed Fix Version/s: 0.21 Merged to 0.22: http://svn.apache.org/r1461545 Message::getRedelivered() always returns true for messages received over AMQP 1.0 - Key: QPID-4668 URL: https://issues.apache.org/jira/browse/QPID-4668 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.20 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.21 regardless of whether they have been previously redelivered or not. -- 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-4672) C++ Broker deadlock detaching XmlExchange sessions
Chuck Rolke created QPID-4672: - Summary: C++ Broker deadlock detaching XmlExchange sessions Key: QPID-4672 URL: https://issues.apache.org/jira/browse/QPID-4672 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Environment: C++ Broker, autotools build, make check or run_federation_tests Reporter: Chuck Rolke Priority: Critical Self test federation.FederationTests.test_dynamic_topic locks up. Pstack shows three threads with the same trace: #0 pthread_rwlock_wrlock () #1 qpid::broker::XmlExchange::unbind() #2 qpid::broker::XmlExchange::fedUnbind() #3 qpid::broker::XmlExchange::bind() #4 qpid::broker::Queue::bind() #5 qpid::broker::Broker::bind() #6 qpid::broker::SemanticState::unbindSessionBindings() #7 qpid::broker::SemanticState::closed() #8 qpid::broker::SessionState::~SessionState() #9 qpid::broker::SessionState::~SessionState() #10 qpid::broker::SessionHandler::handleDetach() #11 qpid::amqp_0_10::SessionHandler::detach() The lock occurs because there are two simultaneous session detach calls going on. Each takes out the Rlock and then tries to take out the Wlock. Neither will get the Wlock until everyone else releases their Rlock. Subsequent detach calls fall into the same catch as they get the Rlock but not the Wlock. This condition is present in both the XmlExchange and DirectExchange. I'll have a patch for review shortly. -- 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-4659) [Java Broker] Refactor broker to separate protocol independent from protocol specific classes
[
https://issues.apache.org/jira/browse/QPID-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615264#comment-13615264
]
Rob Godfrey commented on QPID-4659:
---
{quote}
MessageMetaDataTypeRegistry.java doesnt check whether there were no
MessageMetaDataType protocol creator implementations (the service loader has a
method to validate that for you), or whether diffrent types accidentally (or
not) used the same ordinal, it should probably do both?
{quote}
Updated to use the method which checks for at least one instance, also throws
an exception if two types are defined for the same ordinal.
{quote}
Commented out code in MessageConverter_0_10_to_1_0.java ?
and MessageConverter_0_8_to_1_0.java?
{quote}
These were the properties not currently being set. I have changed the comments
to make this clear and no longer make it look like code.
{quote}
Should MessageConverter_1_0_to_0_10.java return null from convert, or perhaps
throw an Unsupported exception? Will it will just NPE after using that method?
The new subscription interest checking seems like it would never try to convert
the messages if we just removed the not-implemented converter.. ?
{quote}
These converters were not actually registered and thus never used. Obviously
in time they should be implemented and registered, but for now I have simply
removed them.
{quote}
Why move this line? Does it log connections to the vhost earlier now as a
result, and then subsequently fail if its denied ACL access or the Vhost isnt
the Master in a HA cluster? If so, do we really want it to do that?
{quote}
I have reverted this change and instead fixed the getVirtualHostName() method
on the various implementations of AMQConnectionModel that were giving NPE with
the setVirtualHost() in its original position.
Not (yet?) addresses:
{quote}
Continuing that theme, should we throw an exception in
MultiVersionProtocolEngineFactory.java if there are no protocol creator
implementations, or more than one was to specify the same header value?
{quote}
Possibly, there probably should be some sort of validation to check that the
intersection of supported versions and available creators is non empty.
{quote}
It seemed preferable when there was an enum for MessageMetaDataType to
reference the ordinals from rather than each type just choosing the int
directly. Obviously if we retained an Enum it would have to go somewhere common
that all the impls could reference it though, and adding new plugins later
would still involve choosing the new int and updating the enum at some point,
so I can kind of see why you just removed it, it jsut felt a little nicer when
it was there.
{quote}
Yeah - it's unfortunate... but I think having an Enum there would sort of
defeat the point of Pluggability. I have modified the code so that each of the
ordinals is now defined as a public constant in the implementing class so they
can be more easily referred to.
[Java Broker] Refactor broker to separate protocol independent from protocol
specific classes
-
Key: QPID-4659
URL: https://issues.apache.org/jira/browse/QPID-4659
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Rob Godfrey
Assignee: Rob Godfrey
The Java Broker currently supports all versions of the AMQP protocol from 0-8
to 1.0, however the current structure of the code within the broker makes it
hard to distinguish between code which is specific to a version of the
protocol and code which is common across all protocols.
By refactoring we can separate the protocol dependent and independent parts
and allow for the possibility of separating out the different protocol
implementations into independently loadable libraries.
Fundamentally the refactoring takes the form of moving protocol specific
classes into org.apache.qpid.server.protocol.v{0-8,0-10,1-0} and sub-packages
and using the QpidClassLoader to load the protocol implementations (there are
three separate implementations to load - the protocol delegate creators that
interface to the IO code; the MessageMetaDataTypes used to (de)serialize the
message data to stores; and MessageConverters used to convert between message
formats and allow 0-8 messages to be received by 1-0 consumers.
--
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-4659) [Java Broker] Refactor broker to separate protocol independent from protocol specific classes
[
https://issues.apache.org/jira/browse/QPID-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615264#comment-13615264
]
Rob Godfrey edited comment on QPID-4659 at 3/27/13 1:50 PM:
{quote}
MessageMetaDataTypeRegistry.java doesnt check whether there were no
MessageMetaDataType protocol creator implementations (the service loader has a
method to validate that for you), or whether diffrent types accidentally (or
not) used the same ordinal, it should probably do both?
{quote}
Updated to use the method which checks for at least one instance, also throws
an exception if two types are defined for the same ordinal.
{quote}
Commented out code in MessageConverter_0_10_to_1_0.java ?
and MessageConverter_0_8_to_1_0.java?
{quote}
These were the properties not currently being set. I have changed the comments
to make this clear and no longer make it look like code.
{quote}
Should MessageConverter_1_0_to_0_10.java return null from convert, or perhaps
throw an Unsupported exception? Will it will just NPE after using that method?
The new subscription interest checking seems like it would never try to convert
the messages if we just removed the not-implemented converter.. ?
{quote}
These converters were not actually registered and thus never used. Obviously
in time they should be implemented and registered, but for now I have simply
removed them.
{quote}
Why move this line? Does it log connections to the vhost earlier now as a
result, and then subsequently fail if its denied ACL access or the Vhost isnt
the Master in a HA cluster? If so, do we really want it to do that?
{quote}
I have reverted this change and instead fixed the getVirtualHostName() method
on the various implementations of AMQConnectionModel that were giving NPE with
the setVirtualHost() in its original position.
Not (yet?) addressed:
{quote}
Continuing that theme, should we throw an exception in
MultiVersionProtocolEngineFactory.java if there are no protocol creator
implementations, or more than one was to specify the same header value?
{quote}
Possibly, there probably should be some sort of validation to check that the
intersection of supported versions and available creators is non empty.
{quote}
It seemed preferable when there was an enum for MessageMetaDataType to
reference the ordinals from rather than each type just choosing the int
directly. Obviously if we retained an Enum it would have to go somewhere common
that all the impls could reference it though, and adding new plugins later
would still involve choosing the new int and updating the enum at some point,
so I can kind of see why you just removed it, it jsut felt a little nicer when
it was there.
{quote}
Yeah - it's unfortunate... but I think having an Enum there would sort of
defeat the point of Pluggability. I have modified the code so that each of the
ordinals is now defined as a public constant in the implementing class so they
can be more easily referred to.
was (Author: rgodfrey):
{quote}
MessageMetaDataTypeRegistry.java doesnt check whether there were no
MessageMetaDataType protocol creator implementations (the service loader has a
method to validate that for you), or whether diffrent types accidentally (or
not) used the same ordinal, it should probably do both?
{quote}
Updated to use the method which checks for at least one instance, also throws
an exception if two types are defined for the same ordinal.
{quote}
Commented out code in MessageConverter_0_10_to_1_0.java ?
and MessageConverter_0_8_to_1_0.java?
{quote}
These were the properties not currently being set. I have changed the comments
to make this clear and no longer make it look like code.
{quote}
Should MessageConverter_1_0_to_0_10.java return null from convert, or perhaps
throw an Unsupported exception? Will it will just NPE after using that method?
The new subscription interest checking seems like it would never try to convert
the messages if we just removed the not-implemented converter.. ?
{quote}
These converters were not actually registered and thus never used. Obviously
in time they should be implemented and registered, but for now I have simply
removed them.
{quote}
Why move this line? Does it log connections to the vhost earlier now as a
result, and then subsequently fail if its denied ACL access or the Vhost isnt
the Master in a HA cluster? If so, do we really want it to do that?
{quote}
I have reverted this change and instead fixed the getVirtualHostName() method
on the various implementations of AMQConnectionModel that were giving NPE with
the setVirtualHost() in its original position.
Not (yet?) addresses:
{quote}
Continuing that theme, should we throw an exception in
MultiVersionProtocolEngineFactory.java if there are no protocol creator
implementations, or more than one was to specify the same header value?
Review Request: C++ Broker XmlExchange deadlocks during simultaneous unbinds
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/ --- Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti. Description --- Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock and then try to upgrade the lock to a Wlock and hang. The failure was intermittent. Only automake builds running 'make check' seemed to have the issue. The fix is to create an unbindLH() function that does the unbind but does not take out the Wlock itself. The note in the Jira about similar behavior in the TopicExchange is wrong; this issue is XmlExchange only. This addresses bug QPID-4672. https://issues.apache.org/jira/browse/QPID-4672 Diffs - trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592 trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592 Diff: https://reviews.apache.org/r/10155/diff/ Testing --- Passes automake and cmake tests. Thanks, Chug Rolke
Re: Review Request: C++ Broker 'rebind' to steer messages from one queue to others
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10020/#review18422 --- trunk/qpid/cpp/src/qpid/broker/Broker.h https://reviews.apache.org/r/10020/#comment38627 I wonder if we could come up with a nicer name... trunk/qpid/cpp/src/qpid/broker/Queue.h https://reviews.apache.org/r/10020/#comment38629 Is there a reason to use a raw pointer rather than a shared pointer? (Not that I see any insurmountable issue either way) trunk/qpid/cpp/src/qpid/broker/Queue.h https://reviews.apache.org/r/10020/#comment38628 Does deliverTo() need to be public? - Gordon Sim On March 26, 2013, 1:54 a.m., Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10020/ --- (Updated March 26, 2013, 1:54 a.m.) Review request for qpid, Gordon Sim and Ted Ross. Description --- To get a true 'atomic rebind' one should (1) freeze all traffic going through all exchanges that have bindings to be changed. Failing that, one could (2) freeze all traffic going through each exchange while that exchange's bindings are changed. A third option would be (3) to freeze each individual binding while it is moved. Options (1) and (2) require per-message locking at the exchange level; these locks do not exist today and adding them would undoubtedly introduce performance degredation. For discussion please see https://issues.apache.org/jira/browse/QPID-4616 and review comments at https://reviews.apache.org/r/9698/ Option (3) requires no new locking and could leverage the locking methods that the exchanges already use. The change proposed here is a prototype that implements lightweight strategy #3. This review exposes what the feature is trying to accomplish and the basic framework is complete. It has: * Queue settings and status. * Management method to trigger the rebind. * Exchange methods to effect the rebind for each exchange type. * Broker changes to handle queues in the 'rebound' state where bind/unbind operations on them actually go to other queues. * Some test suite code to trigger the rebind method and its error paths. * A qpid.rebind exchange for backup agents to use to refill queues that are in rebind state and not accessable through normal bindings. Before this feature could transition to 'Ship It' it still needs: * An ACL property to control specification of rebind queues. * A handler for queue deletion while the queue is part of a rebind set. * Code to restore a queue from rebind state back to normal. * Proof that traffic can be properly recovered through a rebind This addresses bug QPID-4650. https://issues.apache.org/jira/browse/QPID-4650 Diffs - trunk/qpid/cpp/src/qpid/broker/Broker.h 1460944 trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1460944 trunk/qpid/cpp/src/qpid/broker/Queue.h 1460944 trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1460944 trunk/qpid/cpp/src/tests/queue_rebind.py PRE-CREATION trunk/qpid/cpp/src/tests/run_queue_rebind PRE-CREATION trunk/qpid/specs/management-schema.xml 1460944 trunk/qpid/tools/src/py/qpidtoollibs/broker.py 1460944 Diff: https://reviews.apache.org/r/10020/diff/ Testing --- Several tests to exercise rebind code paths. Thanks, Chug Rolke
Re: Review Request: C++ Broker XmlExchange deadlocks during simultaneous unbinds
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/#review18423 --- trunk/qpid/cpp/src/qpid/xml/XmlExchange.h https://reviews.apache.org/r/10155/#comment38630 Should this be public? Other than that, ship it! - Gordon Sim On March 27, 2013, 2:38 p.m., Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/ --- (Updated March 27, 2013, 2:38 p.m.) Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti. Description --- Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock and then try to upgrade the lock to a Wlock and hang. The failure was intermittent. Only automake builds running 'make check' seemed to have the issue. The fix is to create an unbindLH() function that does the unbind but does not take out the Wlock itself. The note in the Jira about similar behavior in the TopicExchange is wrong; this issue is XmlExchange only. This addresses bug QPID-4672. https://issues.apache.org/jira/browse/QPID-4672 Diffs - trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592 trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592 Diff: https://reviews.apache.org/r/10155/diff/ Testing --- Passes automake and cmake tests. Thanks, Chug Rolke
Re: Review Request: C++ Broker XmlExchange deadlocks during simultaneous unbinds
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/#review18424 --- trunk/qpid/cpp/src/qpid/xml/XmlExchange.h https://reviews.apache.org/r/10155/#comment38631 Good point. Moving new function to private. - Chug Rolke On March 27, 2013, 2:38 p.m., Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/ --- (Updated March 27, 2013, 2:38 p.m.) Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti. Description --- Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock and then try to upgrade the lock to a Wlock and hang. The failure was intermittent. Only automake builds running 'make check' seemed to have the issue. The fix is to create an unbindLH() function that does the unbind but does not take out the Wlock itself. The note in the Jira about similar behavior in the TopicExchange is wrong; this issue is XmlExchange only. This addresses bug QPID-4672. https://issues.apache.org/jira/browse/QPID-4672 Diffs - trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592 trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592 Diff: https://reviews.apache.org/r/10155/diff/ Testing --- Passes automake and cmake tests. Thanks, Chug Rolke
[jira] [Commented] (QPID-4672) C++ Broker deadlock detaching XmlExchange sessions
[ https://issues.apache.org/jira/browse/QPID-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615373#comment-13615373 ] Chuck Rolke commented on QPID-4672: --- Fixed in r1461634. https://reviews.apache.org/r/10155/ Will request back port into 0.22 C++ Broker deadlock detaching XmlExchange sessions -- Key: QPID-4672 URL: https://issues.apache.org/jira/browse/QPID-4672 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Environment: C++ Broker, autotools build, make check or run_federation_tests Reporter: Chuck Rolke Priority: Critical Self test federation.FederationTests.test_dynamic_topic locks up. Pstack shows three threads with the same trace: #0 pthread_rwlock_wrlock () #1 qpid::broker::XmlExchange::unbind() #2 qpid::broker::XmlExchange::fedUnbind() #3 qpid::broker::XmlExchange::bind() #4 qpid::broker::Queue::bind() #5 qpid::broker::Broker::bind() #6 qpid::broker::SemanticState::unbindSessionBindings() #7 qpid::broker::SemanticState::closed() #8 qpid::broker::SessionState::~SessionState() #9 qpid::broker::SessionState::~SessionState() #10 qpid::broker::SessionHandler::handleDetach() #11 qpid::amqp_0_10::SessionHandler::detach() The lock occurs because there are two simultaneous session detach calls going on. Each takes out the Rlock and then tries to take out the Wlock. Neither will get the Wlock until everyone else releases their Rlock. Subsequent detach calls fall into the same catch as they get the Rlock but not the Wlock. This condition is present in both the XmlExchange and DirectExchange. I'll have a patch for review shortly. -- 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
0.22 request for change to release branch - XmlExchange deadlock
QPID-4672, approved by Gordon Sim - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4672) C++ Broker deadlock detaching XmlExchange sessions
[ https://issues.apache.org/jira/browse/QPID-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615390#comment-13615390 ] Gordon Sim commented on QPID-4672: -- I concur with backporting to 0.22 C++ Broker deadlock detaching XmlExchange sessions -- Key: QPID-4672 URL: https://issues.apache.org/jira/browse/QPID-4672 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Environment: C++ Broker, autotools build, make check or run_federation_tests Reporter: Chuck Rolke Priority: Critical Self test federation.FederationTests.test_dynamic_topic locks up. Pstack shows three threads with the same trace: #0 pthread_rwlock_wrlock () #1 qpid::broker::XmlExchange::unbind() #2 qpid::broker::XmlExchange::fedUnbind() #3 qpid::broker::XmlExchange::bind() #4 qpid::broker::Queue::bind() #5 qpid::broker::Broker::bind() #6 qpid::broker::SemanticState::unbindSessionBindings() #7 qpid::broker::SemanticState::closed() #8 qpid::broker::SessionState::~SessionState() #9 qpid::broker::SessionState::~SessionState() #10 qpid::broker::SessionHandler::handleDetach() #11 qpid::amqp_0_10::SessionHandler::detach() The lock occurs because there are two simultaneous session detach calls going on. Each takes out the Rlock and then tries to take out the Wlock. Neither will get the Wlock until everyone else releases their Rlock. Subsequent detach calls fall into the same catch as they get the Rlock but not the Wlock. This condition is present in both the XmlExchange and DirectExchange. I'll have a patch for review shortly. -- 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: C++ Broker XmlExchange deadlocks during simultaneous unbinds
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10155/#review18425
---
Ship it!
Looks fine - but I'm not a big fan of the xxxLH() convention, though. It's too
brittle. A code change that (re)moves the lock will cause the code to fail,
but cannot be detected by the compiler. Not much of an issue if the developer
is careful, but a real problem when backporting patches.
My preference - while not a very popular one - is to change the parameter list
of the xxxLH() call to take a const reference to the held lock, while the
actual function ignores this parameter. This allows the compiler to enforce
that there is a lock around the xxLH() call, since the lock actually has to be
passed. Should a patch be applied that (re)moves the lock, the compilation
will fail.
Example:
ScopedLock l(somelock);
...
xxxLH( param1, param2, ..., l );
with the definition of xxxLH() ignoring that parameter:
void xxxLH( int param1, int param2, ... const ScopedLock /*ignored*/ ) {
I can see why most people don't like this convention - it implies the method
may modify the lock - but the const designation prevents that.
That said, I'm fine with the patch as-is.
- Kenneth Giusti
On March 27, 2013, 2:38 p.m., Chug Rolke wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10155/
---
(Updated March 27, 2013, 2:38 p.m.)
Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti.
Description
---
Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock
and then try to upgrade the lock to a Wlock and hang.
The failure was intermittent. Only automake builds running 'make check'
seemed to have the issue.
The fix is to create an unbindLH() function that does the unbind but does not
take out the Wlock itself.
The note in the Jira about similar behavior in the TopicExchange is wrong;
this issue is XmlExchange only.
This addresses bug QPID-4672.
https://issues.apache.org/jira/browse/QPID-4672
Diffs
-
trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592
trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592
Diff: https://reviews.apache.org/r/10155/diff/
Testing
---
Passes automake and cmake tests.
Thanks,
Chug Rolke
[jira] [Commented] (QPID-3769) NPE in client AMQDestination.equals()
[ https://issues.apache.org/jira/browse/QPID-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615424#comment-13615424 ] Rajith Attapattu commented on QPID-3769: I was going to request a port, but I should have kept this open until then. I also agree on the comments about the tests for this. NPE in client AMQDestination.equals() - Key: QPID-3769 URL: https://issues.apache.org/jira/browse/QPID-3769 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.12 Reporter: Jan Bareš Assignee: Rajith Attapattu Labels: addressing Code of org.apache.qpid.client.AMQDestination.equals(Object) is buggy, it should test for null on _exchangeClass and _exchangeName before dereferencing them, lines 522 and 526. -- 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 into the 0.22 branch
Hey Justin, I want to include the following commits into the 0.22 branch. http://svn.apache.org/r1461324 http://svn.apache.org/r1461329 Once I make some adjustments to the tests, I would need to port that as well. I will send a follow up email when I've got that sorted out. Regards, Rajith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Request for inclusion into the 0.22 branch
Sorry I forgot to include the JIRA in the email. Please see https://issues.apache.org/jira/browse/QPID-3769 for context. Rajith On Wed, Mar 27, 2013 at 12:00 PM, Rajith Attapattu rajit...@gmail.com wrote: Hey Justin, I want to include the following commits into the 0.22 branch. http://svn.apache.org/r1461324 http://svn.apache.org/r1461329 Once I make some adjustments to the tests, I would need to port that as well. I will send a follow up email when I've got that sorted out. Regards, Rajith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: C++ Broker XmlExchange deadlocks during simultaneous unbinds
On March 27, 2013, 3:53 p.m., Kenneth Giusti wrote:
Looks fine - but I'm not a big fan of the xxxLH() convention, though. It's
too brittle. A code change that (re)moves the lock will cause the code to
fail, but cannot be detected by the compiler. Not much of an issue if the
developer is careful, but a real problem when backporting patches.
My preference - while not a very popular one - is to change the parameter
list of the xxxLH() call to take a const reference to the held lock, while
the actual function ignores this parameter. This allows the compiler to
enforce that there is a lock around the xxLH() call, since the lock
actually has to be passed. Should a patch be applied that (re)moves the
lock, the compilation will fail.
Example:
ScopedLock l(somelock);
...
xxxLH( param1, param2, ..., l );
with the definition of xxxLH() ignoring that parameter:
void xxxLH( int param1, int param2, ... const ScopedLock /*ignored*/ ) {
I can see why most people don't like this convention - it implies the
method may modify the lock - but the const designation prevents that.
That said, I'm fine with the patch as-is.
+1
- Alan
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10155/#review18425
---
On March 27, 2013, 2:38 p.m., Chug Rolke wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10155/
---
(Updated March 27, 2013, 2:38 p.m.)
Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti.
Description
---
Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock
and then try to upgrade the lock to a Wlock and hang.
The failure was intermittent. Only automake builds running 'make check'
seemed to have the issue.
The fix is to create an unbindLH() function that does the unbind but does not
take out the Wlock itself.
The note in the Jira about similar behavior in the TopicExchange is wrong;
this issue is XmlExchange only.
This addresses bug QPID-4672.
https://issues.apache.org/jira/browse/QPID-4672
Diffs
-
trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592
trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592
Diff: https://reviews.apache.org/r/10155/diff/
Testing
---
Passes automake and cmake tests.
Thanks,
Chug Rolke
Re: Review Request: C++ Broker XmlExchange deadlocks during simultaneous unbinds
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/#review18429 --- Ship it! Ship It! - Alan Conway On March 27, 2013, 2:38 p.m., Chug Rolke wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10155/ --- (Updated March 27, 2013, 2:38 p.m.) Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti. Description --- Self test federation.test_dynamic_topic hangs. Two threads take out an Rlock and then try to upgrade the lock to a Wlock and hang. The failure was intermittent. Only automake builds running 'make check' seemed to have the issue. The fix is to create an unbindLH() function that does the unbind but does not take out the Wlock itself. The note in the Jira about similar behavior in the TopicExchange is wrong; this issue is XmlExchange only. This addresses bug QPID-4672. https://issues.apache.org/jira/browse/QPID-4672 Diffs - trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1461592 trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1461592 Diff: https://reviews.apache.org/r/10155/diff/ Testing --- Passes automake and cmake tests. Thanks, Chug Rolke
[jira] [Commented] (QPID-4063) Allow user to assign the name of the source queue when creating an exchange or dynamic route.
[ https://issues.apache.org/jira/browse/QPID-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615626#comment-13615626 ] Ted Ross commented on QPID-4063: There's a possible unintended consequence on this patch: If the queue name is supplied, it *must* have been previously declared or the federation bridge will fail to subscribe to the queue. The bridge code assumes that the queue pre-exists if the queue name is supplied. Allow user to assign the name of the source queue when creating an exchange or dynamic route. - Key: QPID-4063 URL: https://issues.apache.org/jira/browse/QPID-4063 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.17 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Trivial Attachments: QPID-4063.txt When a federation route is created - either an exchange or a dynamic route - a dedicated queue is created on the source broker. This queue is used to hold messages that are forwarded to the remote broker. This queue is created by federation, and assigned a (somewhat) randomized name. It should be possible - as an option - to allow the user to specify the name for that queue. This would be useful for a couple of reasons... 1) Monitoring the state of the queue would be easier if it had a meaningful name. 2) Power Users could specify an existing queue, which could then be used as a target for messages that should be forwarded over the federation, 3) Allow several routes share the same queue (if msg ordering need not be preserved) to fan out work across a federation. -- 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-4063) Allow user to assign the name of the source queue when creating an exchange or dynamic route.
[ https://issues.apache.org/jira/browse/QPID-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved QPID-4063. -- Resolution: Fixed Fix Version/s: 0.18 http://svn.apache.org/viewvc?view=revisionrevision=1351518 http://svn.apache.org/viewvc?view=revisionrevision=1351519 Forgot to resolve this - thanks Ted for the reminder! Allow user to assign the name of the source queue when creating an exchange or dynamic route. - Key: QPID-4063 URL: https://issues.apache.org/jira/browse/QPID-4063 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.17 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Trivial Fix For: 0.18 Attachments: QPID-4063.txt When a federation route is created - either an exchange or a dynamic route - a dedicated queue is created on the source broker. This queue is used to hold messages that are forwarded to the remote broker. This queue is created by federation, and assigned a (somewhat) randomized name. It should be possible - as an option - to allow the user to specify the name for that queue. This would be useful for a couple of reasons... 1) Monitoring the state of the queue would be easier if it had a meaningful name. 2) Power Users could specify an existing queue, which could then be used as a target for messages that should be forwarded over the federation, 3) Allow several routes share the same queue (if msg ordering need not be preserved) to fan out work across a federation. -- 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-4673) [Java Broker AMQP 1.0] Potential for deadlock when draining AMQP 1.0 subscriptions
Rob Godfrey created QPID-4673: - Summary: [Java Broker AMQP 1.0] Potential for deadlock when draining AMQP 1.0 subscriptions Key: QPID-4673 URL: https://issues.apache.org/jira/browse/QPID-4673 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.20 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.21 There is a potential for deadlock between the locks on the connection endpoint and the subscription object in the java broker when running in the AMQP 1.0 codepath. Instead of locking the subscription object the methods should instead take the lock from the link (which is the same as the connection endpoint lock). -- 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: 0.22, request for merge (create link lockdown)
I would like to merge the feature from qpid/branches/qpid-4631 into the 0.22 release. It is a forceful lockdown of the interbroker links using ACLs as described in https://issues.apache.org/jira/browse/QPID-4631. The patch changes the behavior of link creation significantly but I think for the better. If merged today the selftests pass cmake 'make test' and automake 'make check'. Regards, Chuck - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
0.22, Request for merge
Hi Justin, request to merge QPID-4673 [1][2] to 0.22. This is a fix to a deadlock which occurs in the Java Broker when running in the AMQP 1.0 codepath. There is no impact to non 1.0 users. Cheers, Rob [1] https://issues.apache.org/jira/browse/QPID-4673 [2] http://svn.apache.org/viewvc?view=revisionrevision=r1461844
[jira] [Commented] (QPID-4672) C++ Broker deadlock detaching XmlExchange sessions
[ https://issues.apache.org/jira/browse/QPID-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615776#comment-13615776 ] Justin Ross commented on QPID-4672: --- Reviewed by Gordon. Approved for 0.22. C++ Broker deadlock detaching XmlExchange sessions -- Key: QPID-4672 URL: https://issues.apache.org/jira/browse/QPID-4672 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Environment: C++ Broker, autotools build, make check or run_federation_tests Reporter: Chuck Rolke Priority: Critical Self test federation.FederationTests.test_dynamic_topic locks up. Pstack shows three threads with the same trace: #0 pthread_rwlock_wrlock () #1 qpid::broker::XmlExchange::unbind() #2 qpid::broker::XmlExchange::fedUnbind() #3 qpid::broker::XmlExchange::bind() #4 qpid::broker::Queue::bind() #5 qpid::broker::Broker::bind() #6 qpid::broker::SemanticState::unbindSessionBindings() #7 qpid::broker::SemanticState::closed() #8 qpid::broker::SessionState::~SessionState() #9 qpid::broker::SessionState::~SessionState() #10 qpid::broker::SessionHandler::handleDetach() #11 qpid::amqp_0_10::SessionHandler::detach() The lock occurs because there are two simultaneous session detach calls going on. Each takes out the Rlock and then tries to take out the Wlock. Neither will get the Wlock until everyone else releases their Rlock. Subsequent detach calls fall into the same catch as they get the Rlock but not the Wlock. This condition is present in both the XmlExchange and DirectExchange. I'll have a patch for review shortly. -- 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: Request for inclusion into the 0.22 branch
Hi, Rajith. I read the jira comments, and it looks like a little more work is required before we put it on the release branch (the testing for the jndi case). On Wed, Mar 27, 2013 at 12:04 PM, Rajith Attapattu rajit...@gmail.com wrote: Sorry I forgot to include the JIRA in the email. Please see https://issues.apache.org/jira/browse/QPID-3769 for context. Rajith On Wed, Mar 27, 2013 at 12:00 PM, Rajith Attapattu rajit...@gmail.com wrote: Hey Justin, I want to include the following commits into the 0.22 branch. http://svn.apache.org/r1461324 http://svn.apache.org/r1461329 Once I make some adjustments to the tests, I would need to port that as well. I will send a follow up email when I've got that sorted out. Regards, Rajith - 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: 0.22, request for merge (create link lockdown)
Hi, Chuck. I think we should agree to land this on trunk first (I'm definitely in favor of it). That way it can get some cycles with CI. Justin On Wed, Mar 27, 2013 at 4:42 PM, Chuck Rolke cro...@redhat.com wrote: I would like to merge the feature from qpid/branches/qpid-4631 into the 0.22 release. It is a forceful lockdown of the interbroker links using ACLs as described in https://issues.apache.org/jira/browse/QPID-4631. The patch changes the behavior of link creation significantly but I think for the better. If merged today the selftests pass cmake 'make test' and automake 'make check'. Regards, Chuck - 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
[jira] [Commented] (QPID-4673) [Java Broker AMQP 1.0] Potential for deadlock when draining AMQP 1.0 subscriptions
[ https://issues.apache.org/jira/browse/QPID-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615794#comment-13615794 ] Justin Ross commented on QPID-4673: --- Isolated to 1.0 protocol module. Approved for 0.22. [Java Broker AMQP 1.0] Potential for deadlock when draining AMQP 1.0 subscriptions -- Key: QPID-4673 URL: https://issues.apache.org/jira/browse/QPID-4673 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.20 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.21 There is a potential for deadlock between the locks on the connection endpoint and the subscription object in the java broker when running in the AMQP 1.0 codepath. Instead of locking the subscription object the methods should instead take the lock from the link (which is the same as the connection endpoint lock). -- 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: Request for inclusion into the 0.22 branch
On Wed, Mar 27, 2013 at 5:31 PM, Justin Ross justin.r...@gmail.com wrote: Hi, Rajith. I read the jira comments, and it looks like a little more work is required before we put it on the release branch (the testing for the jndi case). Indeed, this review request is for the whole package :P I will email with the commit URL once the tests are committed. I'm sorting through something else at the moment. Rajith On Wed, Mar 27, 2013 at 12:04 PM, Rajith Attapattu rajit...@gmail.com wrote: Sorry I forgot to include the JIRA in the email. Please see https://issues.apache.org/jira/browse/QPID-3769 for context. Rajith On Wed, Mar 27, 2013 at 12:00 PM, Rajith Attapattu rajit...@gmail.com wrote: Hey Justin, I want to include the following commits into the 0.22 branch. http://svn.apache.org/r1461324 http://svn.apache.org/r1461329 Once I make some adjustments to the tests, I would need to port that as well. I will send a follow up email when I've got that sorted out. Regards, Rajith - 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4666) Incorrect exception message returned in MessageSubscribe when permission is denied
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-4666: Assignee: Robbie Gemmell Incorrect exception message returned in MessageSubscribe when permission is denied -- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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-4666) Incorrect exception message returned in MessageSubscribe when permission is denied
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4666: - Fix Version/s: 0.21 Incorrect exception message returned in MessageSubscribe when permission is denied -- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Fix For: 0.21 Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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-4666) Incorrect exception message returned in MessageSubscribe when permission is denied
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4666: - Fix Version/s: (was: 0.21) 0.22 Incorrect exception message returned in MessageSubscribe when permission is denied -- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Fix For: 0.22 Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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-4666) [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4666: - Summary: [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure (was: Incorrect exception message returned in MessageSubscribe when permission is denied) [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure --- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Fix For: 0.22 Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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-4666) [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615889#comment-13615889 ] Robbie Gemmell commented on QPID-4666: -- Hi JAkub, I had a chat with Rob and we thought that including the queue name and the destination would probably be a good idea, so I have made that change on trunk. I fixed a typo in a related exception as well and so have tweaked the JIRA title accordingly. The change was committed as http://svn.apache.org/r1461895 If you let me know this works ok for you I'll then request it for inclusion in 0.22. Robbie [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure --- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Fix For: 0.22 Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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-4666) [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure
[ https://issues.apache.org/jira/browse/QPID-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4666: - Affects Version/s: 0.6 0.8 0.10 0.12 0.14 0.16 0.18 0.20 [Java Broker] Incorrect exception messages returned following 0-10 MessageSubscribe failure --- Key: QPID-4666 URL: https://issues.apache.org/jira/browse/QPID-4666 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20 Environment: Linux, Java 1.6, Qpid Java Client 0.20, Qpid Java Broker 0.23 (trunk) Reporter: JAkub Scholz Assignee: Robbie Gemmell Priority: Minor Fix For: 0.22 Attachments: client.log, QPID-4666a.patch, QPID-4666.patch When AMQP client tries to subscribe to a queue which he is not allowed to assign to due to insufficient ACL rights, he seems to receive a slightly incorrect error message: Cannot subscribe to '1': Permission denied instead of: Cannot subscribe to 'queueName': Permission denied -- 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
