On 30 May 2008, at 09:53, khudalla wrote:
Hi,
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.
I wonder whether the ActiveMQSession.run() 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:
http://www.nabble.com/Handling-of-RuntimeExceptions-in-ActiveMQSession.run%28%29-method-tp17554360s2354p17554360.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
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
exceptions
cheers,
Rob
http://open.iona.com/products/enterprise-activemq
http://rajdavies.blogspot.com/
