On Thu, 2010-01-07 at 11:19 -0800, zdvickery wrote: > > Timothy Bish wrote: > > > > 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. > > > > The issue in my mind is to understand "what is the correct behavior of these > events?" and then to ensure the library meets the specification. Right now, > what these events do seems to predicated on the use of failover transport, > whether it is associated with a publisher or subscriber, and the NMS > version. It's more of a specification effort than anything; I'm not sure if > that's what you want logged in Jira.
I would expect that if the Connection is broken between the NMS client and the Broker and it were actually detected (FIN packet sent for instance) than if you had an ExceptionListener connected to the Connection instance that you'd see an onException callback. Without looking into the code it sounds like a bug, but I'd need to see your client code to know for sure that things are setup correctly. If you create an issue and attach a sample app that you think should be receiving the exception notification when the broker is killed for instance I can look into it. In cases where there's no FIN packet then all bets are off, it could hang around forever unless you do a send or have the inactivity monitor enabled. > > As far as the connection is concerned, there are two scenarios which seem to > produce identical behavior in the NMS library. I haven't sniffed them to > determine if they are being closed with a FIN or RST: > - ActiveMQ is restarted > - SSH tunnel used for transport is closed Regards Tim.
