From users-return-199626-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Thu Jul 23 20:27:31 2009 Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 60030 invoked from network); 23 Jul 2009 20:27:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Jul 2009 20:27:31 -0000 Received: (qmail 91037 invoked by uid 500); 23 Jul 2009 20:28:32 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 90970 invoked by uid 500); 23 Jul 2009 20:28:32 -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 90959 invoked by uid 99); 23 Jul 2009 20:28:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 20:28:32 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.61.61.105] (HELO usea-naimss3.unisys.com) (192.61.61.105) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2009 20:28:18 +0000 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.20]) by usea-naimss3 with InterScan Message Security Suite; Thu, 23 Jul 2009 15:27:56 -0500 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.55]) by usea-nagw3.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:27:56 -0500 Received: from usea-nahubcas1.na.uis.unisys.com ([129.224.76.114]) by usea-nagw3.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:27:56 -0500 Received: from USEA-EXCH7.na.uis.unisys.com ([129.224.76.38]) by usea-nahubcas1.na.uis.unisys.com ([129.224.76.114]) with mapi; Thu, 23 Jul 2009 15:27:55 -0500 From: "Caldarale, Charles R" To: Tomcat Users List Date: Thu, 23 Jul 2009 15:27:54 -0500 Subject: RE: Logging servlet time and connections Thread-Topic: Logging servlet time and connections Thread-Index: AcoLzyhtLXPfhHbLRCyqFZbNXg2okgAARdzQ Message-ID: <0AAE5AB84B013E45A7B61CB66943C17229A25CC999@USEA-EXCH7.na.uis.unisys.com> References: <20090723101004.d9p52o99gk088o0s@www.thetimmermans.net> <0AAE5AB84B013E45A7B61CB66943C17229A25CC139@USEA-EXCH7.na.uis.unisys.com> <20090723145535.koesp4hy8k0k84gs@www.thetimmermans.net> <0AAE5AB84B013E45A7B61CB66943C17229A25CC71F@USEA-EXCH7.na.uis.unisys.com> <4A68BF6B.1030404@ptc.com> In-Reply-To: <4A68BF6B.1030404@ptc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2009 20:27:56.0372 (UTC) FILETIME=[100CB140:01CA0BD4] X-Virus-Checked: Checked by ClamAV on apache.org > From: Jess Holle [mailto:jessh@ptc.com] > Subject: Re: Logging servlet time and connections >=20 > In this scenario once you exceed maxThread minus 2 simultaneous > connections (there's a clear off by 2 error here somewhere) any > additional simultaneous connections go into some sort of weird > limbo, are never processed, and eventually time out. That would be expected, since AJP connections are intended to be persistent= . Once the max connections have been established, Tomcat gets no indicatio= n that more are needed, since that's all handled by the TCP/IP stack, not T= omcat or the JVM. The "weird limbo" is likely just the normal TCP/IP accep= t queue. (There's no timeout limit for that queue - the server is expected= to do accepts within a "reasonable" amount of time and get the connection = requests off the queue; TCP clients can specify a timeout for the request.)= It's extremely important to have compatible configurations for Tomcat and= httpd when using AJP. > This is irrespective of the value of acceptCount used, which is simply > ignored in this case! It's not ignored - incoming requests that would exceed the acceptCount are = refused; some server TCP/IP stacks send an RST back when the accept queue i= s full, some just silently discard the SYN. Tomcat has no way of finding o= ut that refusals happened. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MA= TERIAL and is thus for use only by the intended recipient. If you received = this in error, please contact the sender and delete the e-mail and its atta= chments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org