> > That will require a little more debugging however. > I've looked at this a little bit. 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.
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. Regards, Chuck ----- Original Message ----- > From: "Gordon Sim" <[email protected]> > To: [email protected] > Sent: Thursday, January 5, 2012 8:00:27 AM > Subject: Re: Heartbeats in C++ broker on Windows > > On 01/04/2012 12:03 PM, wolfwolfswinkel wrote: > > The patch fixes my first issue (the broker not sending heartbeats). > > > > Unfortunately the second issue persists. Now I trigger a heartbeat > > timeout > > in the client by disconnecting a network cable. The client notices > > the > > missing heartbeat (shows the "debug Traffic timeout" message), but > > then does > > not do any reconnect attempts. When the Sender is up to capacity, > > it seems > > to block indefinitely in a sync() call. Stack trace below. > > That looks like a problem on the client side. When the heartbeat > fires > it asks the AsynchIO part of the library to callback on an IO thread > (AsynchIO::requestCallback()). The callback function is > TCPConnector::eof() which just calls TCPConnector::close() which then > calls AsynchIO::queueWriteClose(). That should result in the socket > being closed and the application being notified of the closed socket. > > As far as I can see, the only part that differs between windows and > linux here is the AsyncIO implementation. My guess is that either the > callback mechanism on AsynchIO isn't working as expected on windows, > or > somehow the close that it triggers isn't actually closing the socket > and > notifying the application as expected. > > That will require a little more debugging however. > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
