[
https://issues.apache.org/activemq/browse/AMQ-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies resolved AMQ-1760.
-----------------------------
Assignee: Rob Davies
Fix Version/s: 5.2.0
Resolution: Fixed
According to the JMS API - an exception should be raised on the
ExceptionListener if their is a serious problem with the Connection Object
- see
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ExceptionListener.html
Applications typically interpret this as a connection error and try to
reconnect. We have to now been calling onException for all client related
issues, which are either application or container related.
Fixed by SVN revision 663059
> Client internal exceptions occurring during async message processing should
> not be propagated to Connection's ExceptionListener
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1760
> URL: https://issues.apache.org/activemq/browse/AMQ-1760
> Project: ActiveMQ
> Issue Type: Improvement
> Affects Versions: 5.1.0
> Reporter: Kai Hudalla
> Assignee: Rob Davies
> Priority: Minor
> Fix For: 5.2.0
>
> Attachments: ExceptionListener.patch
>
>
> I have stumbled across the following code in the ActiveMQSession.run() method:
> try {
> messageListener.onMessage(message);
> } catch (Throwable e) {
> // TODO: figure out proper way to handle error.
> LOG.error("error dispatching message: ", e);
> connection.onAsyncException(e);
> }
> As the TODO points out, the way how to handle exceptions properly needs some
> discussion. I have come across this while working on the Resource Adapter in
> conjunction with GlassFish v2. When I use batching when delivering messages
> to an MDB and the MDB marks the current TX as rollback only (e.g. if it
> cannot access a database), any subsequent invocation of the MDB's onMessage()
> method (actually the invocation of the wrapper around that method provided by
> the GlassFish app server) in the same TX will throw a
> javax.ejb.TransactionRolledbackLocalException in order to indicate that it is
> futile to invoke the bean since the TX will be rolled back anyway. This
> RuntimeException will now lead to the catch block being executed, i.e. the
> connection's ExceptionListener will be notified eventually which in this case
> is the listener that the RA has registered on the connection which in turn
> will tear down the connection and reconnect to the broker. However, the
> connection never failed in the first place, i.e. reconnecting to the broker
> is not necessary at all.
> After some discussion with Rob Davies we are proposing to
> add another method on Connection - e.g.
> setClientInternalExceptionListener() - that registers an exception
> listener of internal exceptions only - like in this
> ActiveMQSession.run() case.
> We then only pass exceptions to the ExceptionListener registered by
> setExceptionListener() that directly affect the connection.
> The ActiveMQSession.run() method will then notify the
> ClientInternalExceptionListener of the runtime problem within the container.
> I have attached a proposed patch that adds this functionality to
> ActiveMQConnection and ActiveMQSession.
> Kai
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
