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://127.0.0.1:61616?transport.useInactivityMonitor=true" > > 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: http://old.nabble.com/ExceptionListener-behavior-in-Connection-class-and-NMS-1.2.0-tp27026733p27065051.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
