[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875782#comment-14875782
]
ASF subversion and git services commented on QPIDJMS-110:
---------------------------------------------------------
Commit 603a5f4c0cbdcf910e917edf333f453ad8943450 in qpid-jms's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=603a5f4 ]
QPIDJMS-110: fix test issue causing sporadic failures
> 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
> Fix For: 0.6.0
>
>
> 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
