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://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.
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 possible. When you say the TCP connect is getting closed reset, who exactly is closing / resetting the connection? Regards Tim. -- Tim Bish http://fusesource.com http://timbish.blogspot.com/
