qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
Date Tue, 15 Sep 2015 16:30:45 GMT

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

Robbie Gemmell edited comment on QPIDJMS-110 at 9/15/15 4:29 PM:
-----------------------------------------------------------------

Thanks for raising this..I'd guess that the processing of the remote detach (which as you
note, is occuring) isn't tripping the failure out the outstanding send task, giving the effect
you see. It could be argued the broker should possibly have rejected the message, but given
the same scenario could happen for other reasons anyway the client should handle it anyway.
I'll take a look tomorrow.


was (Author: gemmellr):
Thanks for raising this..I'd guess that the processing of the remote detach (whicha re you
note, is occuring) isn't tripping the failure out the outstanding send task, giving the effect
you see. It could be argued the broker should possibly have rejected the message, but given
the same scenario could happen for other reasons anyway the client should handle it anyway.
I'll take a look tomorrow.

> 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
>
> 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