sounds pretty straight forward to me, remove most of the test
basically
1. set regular soTimeout (connectionTimeout)
-- loop starts here--
2. read the request line and headers
3. check disableupload, if set to true, increase soTimeout to what ever
we use
4. At the end of the request, if user specified a value for keepalive
timeout setSoTimeout(keepAliveTimeout)
otherwise set regular soTimeout
-- loop ends here --
The cost of setting setSoTimeout is not high.
So you still need at least two checks (step 3 and 4)
Filip
Mark Thomas wrote:
Folks,
https://issues.apache.org/bugzilla/show_bug.cgi?id=46666 highlighted
some issues that have now been fixed. In commenting on the fix, Bill said:
<quote>
The original was an optimization to not keep setting the timeout to the
same value if we haven't changed it. Of course it is broken, but a
better patch would be to set the timeout correctly outside the loop, and
retain the disableUploadTimeout check. The first request shouldn't care,
since we should already have available() > 0 with the JIO connector.
</quote>
My response was:
<quote>
I took a look at this. I think you do have to set timeouts inside the
loop otherwise the request line read doesn't timeout correctly. I wrote
this patch that only sets timeouts when required:
http://people.apache.org/~markt/patches/2009-02-12-soTimeout.patch
but I'm not sure it is necessary. Is setSoTimeout really that expensive?
It takes less than a microsecond on my box. The code would be cleaner if
we just took out most of the tests and set the timeout, even if it was
already set as required.
</quote>
So, what do people think. Use the patch above or remove most of the
tests and just set the timeout?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
