trying to understand exactly how the server knows when a client fails

[greg <gr...@bt.com>]

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.

Re: trying to understand exactly how the server knows when a client fails

[greg <gr...@bt.com>]

i was hoping this was the case and that the killed process was saying a last
goodbye on the way out.

this is a nice behavior.  i've just recently run similar tests using hornetq
where killing the java process (or having it crash) did not result in the
server becoming aware so quickly.  i certainly prefer the behavior provided
by the activemq tcp transport.

-- 
View this message in context: http://activemq.2283324.n4.nabble.com/trying-to-understand-exactly-how-the-server-knows-when-a-client-fails-tp3047186p3047440.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: trying to understand exactly how the server knows when a client fails

[Stan Lewis <sl...@fusesource.com>]

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 <gr...@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.
>

Re: trying to understand exactly how the server knows when a client fails

[greg <gr...@bt.com>]

The confusion i have with such a fast client failure detection being possible
is that it would appear to be at odds with the various default timeout
settings such as maxInactivityDuration.

I was hoping someone could point me to either a forum post or a doc page or
even just a keyword to search for in the code that can help me understand
how and where this is configured.
-- 
View this message in context: http://activemq.2283324.n4.nabble.com/trying-to-understand-exactly-how-the-server-knows-when-a-client-fails-tp3047186p3047323.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: trying to understand exactly how the server knows when a client fails

[Nageswara <NN...@dwd.IN.gov>]

The basic I understood is...the frequency of a handshake / ping message to
know the server is dead might be very very very less, that it appears like
instantaneous.

If I am expecting message "I am ALIVE"from a person "Jack Daniels" 10,000
times/Sec..., when ever I have no reply... Jack Daniels was dead.

-----

Nageswara P Nakarikanti
-- 
View this message in context: http://activemq.2283324.n4.nabble.com/trying-to-understand-exactly-how-the-server-knows-when-a-client-fails-tp3047186p3047306.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.