activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <>
Subject Re: Handling of RuntimeExceptions in method
Date Fri, 30 May 2008 10:45:21 GMT

On 30 May 2008, at 09:53, khudalla wrote:

> Hi,
> I have stumbled across the following code in the
> 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.
> I wonder whether the method should better  
> ignore any
> RuntimeException thrown by the MessageListener (i.e. do not invoke
> connection.onAsyncException()) since these exceptions generally  
> indicate a
> problem with the processing of the message, not with receiving the  
> message.
> Any thoughts?
> Kai
> -- 
> View this message in context:
> Sent from the ActiveMQ - Dev mailing list archive at

Hi Kai,

Thanks for the feedback and good description of the problem! The  
problem is that the only mechanism to notify of an internal async  
exception is through the Connection Exception listener - and and we  
use this for both internal client exceptions - and actual transport  
exceptions. However, I agree that this is erroneous - according to the  
JMS API - onException() should only be called if there is a serious  
problem with the Connection object itself.

We do call this from multiple places in the client side code -  
normally to notify that there is a runtime exception from the  
container (as in this case) or the application when consuming a  
message asynchronously.

I think we need to add an additional method on the Connection for  
registering an Exception listener for general client/application  



View raw message