tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lee Rubinger <>
Subject Re: Tomcat/AJP Client Abort Socket Errors - Leads to File Descriptor Leak
Date Thu, 26 Jul 2007 19:40:27 GMT
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.


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
>>> 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:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message