From users-return-5720-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Fri Jan 6 10:39:40 2012 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B28C0BFAC for ; Fri, 6 Jan 2012 10:39:40 +0000 (UTC) Received: (qmail 97371 invoked by uid 500); 6 Jan 2012 10:39:40 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 96783 invoked by uid 500); 6 Jan 2012 10:39:26 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 96272 invoked by uid 99); 6 Jan 2012 10:39:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jan 2012 10:39:15 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jan 2012 10:39:08 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q06Ackqs019819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jan 2012 05:38:46 -0500 Received: from [10.3.231.149] (vpn-231-149.phx2.redhat.com [10.3.231.149]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q06AcjoD014212 for ; Fri, 6 Jan 2012 05:38:46 -0500 Message-ID: <4F06CF22.7070801@redhat.com> Date: Fri, 06 Jan 2012 10:38:26 +0000 From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parsons (USA), Charlie Peters (USA) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Heartbeats in C++ broker on Windows References: <1ec09e99-167f-469f-bb89-3fecdcac1f99@zmail16.collab.prod.int.phx2.redhat.com> In-Reply-To: <1ec09e99-167f-469f-bb89-3fecdcac1f99@zmail16.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 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