[
https://issues.apache.org/jira/browse/QPID-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036371#comment-13036371
]
Rajith Attapattu commented on QPID-3234:
----------------------------------------
The AMQP spec defines Connection errors as hard errors and Execution (Session)
exceptions as soft errors.
So there is no question about how to determine if it's a hard error or not.
Unfortunately JMS does not have a session level exception listener to notify
errors if the client is in a passive mode.
Ex. When using a message listener.
Therefore as explained above in some cases a session error is infact a serious
issue that has to be notified and the only way to do so is the connection
exception listener.
On the other hand, I do hear your point about the rest of the sessions being
closed due to an error in just one session. It's not ideal, but given the
limitation in JMS seems like a necessary evil.
It's probably better to for all the sessions to get canned and recreated than
just one session silently failing and the application not knowing about it.
From that perspective, I think the current behaviour makes sense.
> Exception handling logic is incorrect in AMQConnection.java
> -----------------------------------------------------------
>
> Key: QPID-3234
> URL: https://issues.apache.org/jira/browse/QPID-3234
> Project: Qpid
> Issue Type: Bug
> Reporter: Rajith Attapattu
>
> IMO there are two issues here.
> 1. The exception listener gets notified of session level exceptions.
> 2. A session level exception causes the connection to be closed along with
> the other sessions.
> 1. We shouldn't notify the connection's exception listener when there is a
> session level error. The JMS API doc clearly states,
> "If a JMS provider detects a serious problem with a Connection object, it
> informs the Connection object's ExceptionListener, if one has been
> registered. It does this by calling the listener's onException method,
> passing it a JMSException argument describing the problem. "
> So certainly execution exceptions which only invalidates the session should
> not be notified via the exception listener.
> 2. Going further if one looks at the AMQConnection.java exceptionReceived()
> method,
> It seems that an execution exception can in fact close the underlying
> connection (and the rest of the sessions) due to the following piece of logic.
> if (hardError(cause))
> {
> closer = (!_closed.getAndSet(true)) || closer;
> { _logger.info("Closing AMQConnection due to :" + cause); }
> }
> Digging further for any AMQException hardError method will return true.
> Therefore we need to rework that piece of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
