qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Heartbeats in C++ broker on Windows
Date Fri, 06 Jan 2012 10:38:26 GMT
On 01/05/2012 11:20 PM, Chuck Rolke wrote:
>>
>> That will require a little more debugging however.
>>
>
> I've looked at this a little bit.

Thanks, Chuck!

> I have a windows client running the
> main.cpp from this thread. The test I run is to let the client send
> the first two messages. Then during the pause I pull the network
> cable. After the pause the client sends messages 3..51. Finally, plug
> the network cable back in and see what happens.

The issue raised by Wolf (as I understand it) is that with AMQP 
heartbeats enabled on the client, the client should detect the loss of 
connectivity while the cable is unplugged, should close the socket and 
since reconnect is enabled it should then try to reconnect.

However on windows it appeared as if this was not happening. The sending 
thread was blocked waiting for completion rather than having detected 
the loss of connection and going into the reconnection logic.

> With a LINUX broker the client restarts shortly after restoring the
> connection. With a (patched) WINDOWS broker the client appears to
> hang. However, if you wait five minutes the client restarts.
>
> A Wireshark sniffer analysis shows:
>
> With the LINUX broker: after the connection is restored the broker
> sends a TCP frame. The client ACKs the frame, sends a RST, and opens
> a new connection.
>
> With the WINDOWS broker: after the connection is restored the broker
> sends a RST frame to the client and the client ACKs the RST. Then the
> client sits for 300 seconds. During this time netstat shows that the
> TCP connection is in ESTABLISHED state.  Next the client sends a RST
> frame to the broker. Immediately thereafter the client opens a new
> connection and messages start flowing again.
>
> Somehow the tcpconnector code is not processing the received RST in a
> timely manner. I'll look at that next.

This sounds like(?) the differences at the TCP level in detecting the 
loss of connectivity, which is a different question from the AMQP 
heartbeating (though interesting nonetheless).

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message