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 21:34:07 GMT
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


View raw message