tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Tomcat keepAliveTimeout
Date Fri, 29 Sep 2006 17:01:13 GMT
Mladen Turk wrote:
> Filip Hanik - Dev Lists wrote:
>> you are correct, soTimeout should not, imho, change depending on the 
>> thread count.
>> if the user sets 20 seconds for soTimeout then it should stay that way.
>>
> 
> Right. With the current code you can only deduct what the actual
> timeout will be. Like said, for 40 sec timeout it can be
> 40, 20, 13 or 2.

This is a (semi useless) feature so that, when the number of threads 
gets lower, it tends to use fewer threads (for HTTP keepalive, in 
particular). It's only for the java.io HTTP connector, which tends to 
eat threads like candy, to prevent it from exhausting the pool too fast.

>> I see how soTimeout would be different from keepAlivetimeout when the 
>> servlet is invoking a blocking read on the servletinputstream.
> 
> Actually its very simple:
> soTimeout: The time to read the data.
> keepAliveTimeout: The time between two requests.
> 
> Those things has been elaborated long time ago.
> I'm sad that my first patch to the Tomcat get reverted immediately
> without any -1. Anyhow, I'll think twice before next commit.

- java.io HTTP connector: soTimeout is used for read() operations 
(keepalive is a blocking read operation)
- APR or NIO HTTP connector: soTimeout is used for the poller timeout, 
as well as timeout for read and write operations

Both allow the disableUploadTimeout flag which increases the timeout 
used while a request is being processed (= when reading a PUT or POST, 
the timeout will be much longer).

 > I see how soTimeout would be different from keepAlivetimeout when the
 > servlet is invoking a blocking read on the servletinputstream.
 > in that case they might want a keepalivetimeout to be fairly long, maybe
 > 15 seconds, and soTimeout to be short, like less than 1 second.
 > but this scenario becomes tricky, if you timeout on a servletinputstream
 > read, is that an exception that the servlet should catch, and does it
 > mean that the request is complete, or should the servlet attempt the
 > read again?

Usually, it's the opposite: when there's a request in progress, you 
don't want to interrupt it, so timeouts are longer. For keepalive, the 
server is allowed to close the connection at any time, so it has no 
consequence for the user. At least it's the usual behavior.

My modification of Mladen's patch was a fix (the patch was not passing 
its values for the APR version) and a change so that keepaliveTimeout 
was equal to soTimeout by default.

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message