From users-return-166642-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Thu Jul 26 19:41:04 2007
Return-Path:
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 96515 invoked from network); 26 Jul 2007 19:41:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 26 Jul 2007 19:41:03 -0000
Received: (qmail 42282 invoked by uid 500); 26 Jul 2007 19:40:50 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 42242 invoked by uid 500); 26 Jul 2007 19:40:50 -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 42215 invoked by uid 99); 26 Jul 2007 19:40:50 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jul 2007 12:40:50 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: 66.111.4.26 is neither permitted nor denied by domain of alr@9mmedia.com)
Received: from [66.111.4.26] (HELO out2.smtp.messagingengine.com) (66.111.4.26)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jul 2007 12:40:48 -0700
Received: from compute2.internal (compute2.internal [10.202.2.42])
by out1.messagingengine.com (Postfix) with ESMTP id 131EDA3FD
for ; Thu, 26 Jul 2007 15:40:28 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160])
by compute2.internal (MEProxy); Thu, 26 Jul 2007 15:40:28 -0400
X-Sasl-enc: D8uwUecM6TnLcJlEDrG96DytDoPfKw+sjQdcRKaXb/s/ 1185478827
Received: from alr.9mmedia.com (firewall.9mmedia.com [216.12.164.18])
by mail.messagingengine.com (Postfix) with ESMTP id BF95843F4
for ; Thu, 26 Jul 2007 15:40:27 -0400 (EDT)
Message-ID: <46A8F8AB.9090509@9mmedia.com>
Date: Thu, 26 Jul 2007 15:40:27 -0400
From: Andrew Lee Rubinger
Reply-To: alr@9mmedia.com
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tomcat Users List
Subject: Re: Tomcat/AJP Client Abort Socket Errors - Leads to File Descriptor
Leak
References: <46A8EDD5.6060002@9mmedia.com> <46A8F283.2040802@kippdata.de> <46A8F524.1040002@9mmedia.com> <46A8F87F.9090101@kippdata.de>
In-Reply-To: <46A8F87F.9090101@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
Thank you so much for all your help. Will post back if a conclusion is
determined, or if it's ruled out that AJP/Tomcat is not the cause.
S,
ALR
Rainer Jung wrote:
> Hi Andrew,
>
> this snapshot looks normal. There are 11 connections used and both sides
> have the same idea about their state.
>
> Web server to Tomcat connections are managed by mod_jk via pools. The
> pool can grow, and if you configure a connection pool idle timeout, it
> will also shrink. Each web server process has its own pool. For Apache
> the default maximum size is equal to the number of request processing
> threads per process.
>
> The prefork Apache MPM uses a single thread per process, so you will end
> up with a single connection per web server process (at least if the
> process already forwarded at most one request to tomcat). The total
> maximum number of connections will then be equal to the maximum number
> of Apache processes configured.
>
> The worker MPM has a configurable number of threads per process, by
> default 25. The total maximum number of connections will be the maximum
> number of processes configured multiplied with the number of threads per
> process.
>
> The default configuration for prefork is 150 processes = connections,
> for worker it is 6 processes with 25 threads each, again = 150 connections.
>
> If your load goes up, the number of processes will grow and more and
> more connections get established.
>
> If you want those to get closed again during idle times, you find hints
> about that in the timeouts document.
>
> Important: you need to set the thread count in the connector element for
> the AJP connector to match the expected maximum of connections, that
> should be handled by Tomcat. Each incoming connection needs a dedicated
> thread, unless you are using the native APR connector.
>
> Keep fd leak hunting. Many admins forget about this tradition.
>
> Regards,
>
> Rainer
>
> Andrew Lee Rubinger wrote:
>> Hi.
>>
>> Rainer Jung wrote:
>>> Do you have special evidence, that the broken piepe errors correlate
>>> to the increase in file descriptors? Or are you only assuming this,
>>> because you can't find any other errors in the logs?
>>
>> Assuming. Should have made this more clear.
>>
>>> Can you see the connections for the file descriptors on the Apache
>>> machine and on the Tomcat machine (using netstat)? Are they in the
>>> same state? Which state?
>>
>> Attached as file. :)
>>
>>> At the moment I see no correlation between the client abort and a
>>> lost backend connection. There is another possible issue, if the file
>>> descriptor leak happens during tiume of low load.
>>
>> FD Leak seems to occur at higher rate during high load.
>>
>>> Since we just had a post about this on the list, I'm simply citing my
>>> last answer from another mail. Even if you think this does not apply
>>> to you, you should read the document the text refers to:
>>> If your analysis is correct, it's a known problem, that firewalls
>>> often drop idle connections, so mod_jk and Tomcat should both be
>>> configured to shut down idle connections. On the Tomcat side you
>>> should use the attribute connectionTimeout in the configuration of
>>> your AJP Connector in server.xml. The units are in milliseconds, so
>>> 10 Minutes would be 600000. On the mod_jk side you should use
>>> connection_pool_timeout, units are seconds, so 10 minutes are 600.
>>
>> Thanks so much; will absolutely look into this.
>>
>>> We have a new docs page about these things, which will go live next
>>> week with our 1.2.24 release. There is a preview for the page under
>>>
>>> http://people.apache.org/~rjung/mod_jk-dev/docs/generic_howto/timeouts.html
>>>
>>>
>>> The next release 1.2.24 will include some improvements for this
>>> situation, but you would still need the timeouts on both ends.
>>
>> Thanks so much for your help. Again, not 100% sure this is a ModJK
>> issue (especially after your comments), but those are my only errors
>> in the logs and it seemed a natural conclusion.
>>
>> S,
>> ALR
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org