When you kill the client JVM the broker would get "connection reset by
peer" as the JVM closes the underlying socket.  I think you'll even
see this if you run wireshark and look at the packets between the
client and broker.

However if you're running the client on a different machine than the
broker and say unplug that machine from the network then you'll see a
lag as the inactivity monitor on the broker side will eventually kick
in and consider the client dead.  During this time if you do an "lsof"
on the broker or "netstat -a" and look for the broker's listen port,
you'll see a connection from the client machine to your broker in
ESTABLISHED state.  This may stay in this state for awhile until the
connection is reaped at the OS level due to TCP keepalive probes not
being answered.

Hope that helps somewhat!

On Wed, Nov 17, 2010 at 12:21 PM, greg <greg.fr...@bt.com> wrote:
>
> i would like to get a better understanding of how the server determines that
> a client is alive. i have been reading about the following parameters as
> much as possible:
>     maxInactivityDuration, connectionTimeout, soTimeout and failover
> settings.
>
> believe it or not, what's puzzling me isn't something bad but something that
> looks too good to be true.
> The test scenario is this:
>  - kill a java jms client from the OS
>  - i am assuming that causes an exit without closing things cleanly.
>  - almost immediately, i see in the server log:  2010-11-17 10:11:15,494 |
> INFO  | Transport failed
>
> in such a case, i would expect the server to have to wait for some timeout
> period based on the above settings before declaring the client as "dead".
> however, the server appears via logs to have nearly instantaneous awareness
> that the client is gone.  i'm not complaining, this seems fantastic but i'd
> like to understand better how it works before i proceed to depend on the
> timing.
>
> thanks,
> greg
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/trying-to-understand-exactly-how-the-server-knows-when-a-client-fails-tp3047186p3047186.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply via email to