activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: ExceptionListener behavior in Connection class and NMS 1.2.0
Date Thu, 07 Jan 2010 19:08:32 GMT
On Thu, 2010-01-07 at 10:52 -0800, zdvickery wrote:
> 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.

If you think you've found an issue then by all means open a new Jira
issue.  We'd need a good description of the problem along with steps to
reproduce it and a sample app that demonstrates the problem if

When you say the TCP connect is getting closed reset, who exactly is
closing / resetting the connection?


Tim Bish

View raw message