tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: keepalive issue
Date Fri, 16 Dec 2011 17:50:06 GMT
Mike Wertheim wrote:
> APR is definitely being loaded.  The DLL is there, and the log says it's
> being used.
> My question was basically: If I'm using APR, can I assume that I'll get the
> APR Connector, or do I need to explicitly specify that I want the APR
> Connector?  (I'm assuming the answer is 'yes' to the first question and
> 'no' the the second question.)
> Also, I reduced the ConnectionTimeout from the 20-second default down to 5
> seconds, and the app seems to work fine.  Would it be advisable to reduce
> it even further?  Assuming that all of my app's users are on a decent DSL
> connection or cable connection, could I get away with reducing it to
> perhaps to 2 seconds, or just 1 second?


The number of milliseconds this Connector will wait, after accepting a connection, for the

request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) 
timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard 
server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds).


The number of milliseconds this Connector will wait for another HTTP request before 
closing the connection. The default value is to use the value that has been set for the 
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.

They are two different things.  It just happens that the default value of the 
keepAliveTimeout is the value of the connectionTimeout (it would not make much sense 

The connectionTimeout comes into play in this scenario :
- a client establishes a TCP connection to your server, and then it does not send a 
request, but just maintains that connection and waits.
Ever heard of DOS attacks ? This is a good way..
Personally, I think that the standard setting of 20 seconds is still quite high.
I cannot imagine why a client would set up a connection to a server, and then not send a 
request for the next 20 seconds, unless it is a malicious client.
(Of course, some clients and some lines are slow, so don't reduce it beyond a reasonable 

But the keepAliveTimeout is the one I was talking about.
It comes into play *after* the response to each request has been sent. The server keeps 
the connection open, in the hope that another request from the client would arrive on it,

before it has to throw away this connection and start all over again for the next request.

But if you know that in your applications, such a "follow-up" request can never come later

than 2 seconds after the first response, then reduce it, maybe to 3-4 seconds, to take 
into account small network delays.
The point is : you want to avoid having to build up and tear down SSL connections more 
than necessary; but you do not want connections and threads sitting doing nothing for too

long either.  So this setting should be a good compromise, /in your situation/.

Take into account that your situation may change over time, so don't set things too sharp.

Change one setting at a time, a little bit at a time, and observe the result.
Many of these settings have indirect effects on others, so it can quickly become confusing

if you change several things at the same time.

And if there was one set of settings which performed best in all cases, then the people 
who make and package Tomcat would have set those already in the default configuration (or

they would be fixed in the code).

> On Fri, Dec 16, 2011 at 8:20 AM, Caldarale, Charles R <
>> wrote:
>>> From: [] On
>> Behalf Of Mike Wertheim
>>> Subject: Re: keepalive issue
>>> In my server.xml, I have this line which turns on APR:
>> "Enables" would be a better word; it does not force the usage of APR.
>>> With this configuration, can I assume that the Connector that I'm using
>> is
>>> the APR/native Connector (the 3rd one in the Connector Comparison table)?
>> No; APR will be used only if the .so (or .dll) can be found and loaded.
>>  The Tomcat logs should tell you whether or not that happened.
>>  - Chuck
>> MATERIAL 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 attachments from all computers.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message