activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zdvickery <>
Subject Re: ExceptionListener behavior in Connection class and NMS 1.2.0
Date Thu, 07 Jan 2010 18:52:00 GMT

Timothy Bish wrote:
> I'd need some more information on your setup to give you a definite
> answer.  Are you using the Failover transport?  If so then the exception
> listener is not notified if the connection is dropped, the Failover
> transport just sits in the background attempting to reconnect.
> In NMS.ActiveMQ 1.2.0-RC2 there is an Inactivity Monitor in the
> transport stack that can be enabled, its new and still undergoing some
> testing so I have disabled it by default, you can enable it by adding
> transport.useInactivityMonitor to your connection URI's options, like
> this:
> 	"tcp://"
> For the non-Failover transport case when the TCP connection is broken
> and finally detected it should cause an exception to fire from the
> Exception listener.  Note however that without the inactivity monitor
> enabled it could take some time for that to happen, I think the keep
> alive on TCP connections in windows is something like an hour or so.
> Regards
> Tim.

All of my initial testing was performed without the failover transport
(which I actually didn't know about until just now).  With that said, I
observe the following behaviors with 1.2-RC2:

No failover transport, no inactivity monitor: Exception listener and
connection interruped listener never fires (even days later)

No failover transport, inactivity monitor enabled: A connection interruped
event fires on the publisher but no event fires on the subscriber.  However
all connections are restored.  This seems to behave very similarly (if not
identically) to the failover transport scenario below.

Failover transport, no inactivity monitor: A connection interruped event
fires on the publisher only and all connections are restored per the backoff
in the failover transport spec

In summary, things work as expected with the failover transport and that is
probably how 99% of developers handle this scenario.  That is a good
solution to my particular problem and I am very happy to discover it. 
However if failover transport is not used (either deliberately or out of
ignorance), the inactivity monitor seems necessary to obtain reasonable
reconnect behavior.  However it seems that in at least the asychronous case
the event behavior makes it difficult (impossible?) for the application to
actually figure out if there is a connection problem, particularly on the
subscriber side.  In addition, the events behave very differently between
NMS versions.

I'm not sure if it is worth the effort to pursue this further, but if so, it
would be good to start with the events and what they should be doing.  For
instance, I'm still unclear whether a TCP connection getting closed/reset
should fire a "connection interruped" event or a "connection exception"
event.  I can create a bug report for this if desired.
View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message