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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
