Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-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 C6CB0DC9F for ; Thu, 1 Nov 2012 22:28:02 +0000 (UTC) Received: (qmail 5485 invoked by uid 500); 1 Nov 2012 22:27:59 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 5432 invoked by uid 500); 1 Nov 2012 22:27:59 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 5422 invoked by uid 99); 1 Nov 2012 22:27:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 22:27:59 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of esmond.pitt@bigpond.com designates 61.9.168.140 as permitted sender) Received: from [61.9.168.140] (HELO nskntmtas02p.mx.bigpond.com) (61.9.168.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 22:27:50 +0000 Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20121101222728.ETJL24575.nskntmtas02p.mx.bigpond.com@nskntcmgw05p>; Thu, 1 Nov 2012 22:27:28 +0000 Received: from HP6910P ([120.151.14.51]) by nskntcmgw05p with BigPond Outbound id JNTU1k00J165irc01NTUtW; Thu, 01 Nov 2012 22:27:28 +0000 X-Authority-Analysis: v=2.0 cv=J5EoHXbS c=1 sm=1 a=4u9tzJkkMcV5r5ibEi6r6w==:17 a=teJ7uTZLJCYA:10 a=JDadKst33uMA:10 a=kj9zAlcOel0A:10 a=1IlZJK9HAAAA:8 a=ucorVbrI_6MA:10 a=tW7pzSPDgYJXBDMp-EAA:9 a=CjuIK1q_8ugA:10 a=4u9tzJkkMcV5r5ibEi6r6w==:117 From: "Esmond Pitt" To: "'Asankha C. Perera'" , "'Tomcat Users List'" References: <50914A4E.501@christopherschultz.net> <509226F1.4070501@apache.org> In-Reply-To: <509226F1.4070501@apache.org> Subject: RE: Handling requests when under load - ACCEPT and RST vs non-ACCEPT Date: Fri, 2 Nov 2012 09:27:24 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac24fArePQUOIDwgTAaGKHrHYCm5IQAAs94g X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Virus-Checked: Checked by ClamAV on apache.org Asankha What you are looking at is TCP platform-dependent behaviour. There is a 'backlog' queue of inbound connections that have been completed by the TCP stack but not yet accepted by the application via the accept() API. This is the queue whose length is specified in the 'C' listen() method (although the platform is free to adjust it either up or down, and generally does so). When the backlog queue fills, the behaviour for subsequent incoming connections is platform-dependent: (a) Windows sends an RST (b) other platforms ignore the incoming connection, in the hope that the backlog will clear and the client will try again. An RST sent because the backlog queue is full is indistinguishable from an RST sent because there is nothing listening at that port, so in either case you should get 'connection refused' or possibly 'connection reset by peer'. Failure to reply at all is indistinguisable from a lost packet, so TCP should retry it a few times before timing out and giving a 'connection timeout'. Whether Windows is correct in sending an RST is debatable but it's been doing it for decades and it certainly isn't going to change. Tomcat and indeed Java have nothing to do with this behaviour, and expecting either to be modified to 'fix' it would be like keeping a dog and barking yourself. EJP --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org