[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
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
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
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
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14802795#comment-14802795
]
Robbie Gemmell commented on QPIDJMS-110:
I've made another change aimed specifically at the second issue described with
sync send(). There are more general changes needed in the related areas I
think, but those will be a larger change on their own JIRA.
> 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
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768829#comment-14768829
]
Robbie Gemmell commented on QPIDJMS-110:
I have put in an initial change for the first issue. The related issue is a bit
more general and will need some more thought. I'm heading out for a while
shortly but will look into that later
> 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
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14767942#comment-14767942
]
ASF subversion and git services commented on QPIDJMS-110:
-
Commit 49aad78c81c33f9268f04c76449afa7fe439381c in qpid-jms's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=49aad78 ]
QPIDJMS-110: ensure deliveries pending update get processed when the producer
link is remotely closed
> 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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747193#comment-14747193
]
Jakub Scholz commented on QPIDJMS-110:
--
Similar scenario is when the queue where the transfer is targeted is full. In
that case, the broker directly closes the connection, resulting in the same
situation in the JMS client - the synchronous send gets stuck. But I guess this
might also happen purely as a race condition, when the detach / connection
close is triggered independently on the transfer, only with a wrong timing and
cause the send to be stuck.
> 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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745682#comment-14745682
]
Robbie Gemmell commented on QPIDJMS-110:
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
