Rob, I do understand that you don't want to skip the mechanism in general in order to not break any existing code that relies on it. However, I am only suggesting to remove the connection.onAsyncException() call in the ActiveMQSession.run() method. The connection that it is called upon is the one the RA has created in order to receive inbound messages for MDBs, i.e. the exception listener is guaranteed to be the one registered by the RA. Thus, no custom code created by developers can be affected by this since such code cannot get a reference to this connection in order to register its own exception listener on the connection, right? Or are you suggesting that the ActiveMQSession.run() method is probably (mis-)used by developers for purposes other than the RA?
Kai rajdavies wrote: > > Hi Kai, > > I agree with what you say - but the original reason we passed > exceptions is that some developers required to know if there was a > problem by this mechanism. ActiveMQ users in general don't try to > reconnect on a Connection.onException() - because they typically use > a fault tolerant failover connection (now the default transport). > > Its to support these users I'm suggesting that we add a supplementary > method to call an exception - and use Connection.onException() for its > proper purpose :) If you don't register an exception listener on this > new method - it won't know anything about it - the exception will just > get logged - which handles your case as well > > cheers, > > Rob > > -- View this message in context: http://www.nabble.com/Handling-of-RuntimeExceptions-in-ActiveMQSession.run%28%29-method-tp17554360s2354p17557168.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
