[ https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14802834#comment-14802834 ]
Jakub Scholz commented on QPIDJMS-110: -------------------------------------- I have retested both scenarios which I mentioned and can confirm that they work fine now. The synchronous send is always interrupted. Thanks for fixing this. > Incorrect error handling when the sender.send(...) call / message transfer > causes an error > ------------------------------------------------------------------------------------------ > > Key: QPIDJMS-110 > URL: https://issues.apache.org/jira/browse/QPIDJMS-110 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client > Reporter: Jakub Scholz > Assignee: Robbie Gemmell > > It seems to me that the error handling doesn't work properly when sending a > message triggers an error (i.e. the sender.send(...) call, not creating > sender). > On the C++ broker, it is easy to configure the access control to allow > message producers to send messages to a certain exchange (topic) only with > some particular subjects / routing keys. When the subject / routing key is > wrong, the C++ broker will raise "unathorized access" error and detach the > link. > I was running this scenario from the Qpid JMS client and it seems that it > doesn't handle the error well: > 1) Connect with the JMS client to the C++ broker > 2) Open a sender to an exchange on the broker (this has to be allowed in the > ACLs on the broker) > 3) Try to send message with subject (i.e. JMSType) which is not allowed in > broker ACLs > 4) The broker detaches the link and the Proton library in the client seems to > handle it, but the client doesn't seem to raise any exception to the outside. > 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES - > RECV: Detach{handle=0, closed=true, > error=Error{condition=amqp:unauthorized-access, description='user1@QPID1234 > cannot publish to broadcast with routing-key bad.routing.key > (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/amqp/Authorise.cpp:118)', > info=null}} > 2015-09-15 17:48:36 +0200 TRACE > org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: LINK_FLOW > 2015-09-15 17:48:36 +0200 TRACE > org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: > LINK_REMOTE_CLOSE > 2015-09-15 17:48:36 +0200 INFO > org.apache.qpid.jms.provider.amqp.AmqpAbstractResource - Resource > JmsProducerInfo {producerId = ID:7W0192-58645-1442332115394-0:1:1:1, > destination = broadcast} was remotely closed > 2015-09-15 17:48:36 +0200 TRACE > org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: > LINK_LOCAL_CLOSE > 2015-09-15 17:48:36 +0200 INFO org.apache.qpid.jms.JmsSession - A JMS > resource has been remotely closed: JmsProducerInfo {producerId = > ID:7W0192-58645-1442332115394-0:1:1:1, destination = broadcast} > 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES - > SENT: Detach{handle=0, closed=true, error=null} > When sending messages asynchronously in a loop, the send(...) call will > finish and few "sent" message later it will throw at least > "javax.jms.JMSException: send not allowed after the sender is closed." > exception. It doesn't contain the original error, but at least it is clear > that something went wrong. So I think that is quite OK. > But when sending messages synchronously, it seems to get stuck in the > send(...) call and never return, although the underlying session is already > gone. I would expect that the send(...) call returns and either throws some > exception directly or through the Exception Listener. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org