[
https://issues.apache.org/activemq/browse/AMQ-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Hudalla updated AMQ-1760:
-----------------------------
Attachment: (was: ExceptionListener.patch)
> 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
> Priority: Minor
> 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.
