qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
Date Thu, 17 Sep 2015 11:47:04 GMT

    [ https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14802780#comment-14802780
] 

ASF subversion and git services commented on QPIDJMS-110:
---------------------------------------------------------

Commit 172c9102ffb94a0d246fcdf967e72a00ce40dc09 in qpid-jms's branch refs/heads/master from
Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=172c910 ]

QPIDJMS-110: ensure outstanding sync send requests are updated when the connection fails [and
failover isnt in use]


> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message