activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-1760) Client internal exceptions occurring during async message processing should not be propagated to Connection's ExceptionListener
Date Wed, 04 Jun 2008 10:53:00 GMT

     [ 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.


Mime
View raw message