Bug 46666 - Why is disableUploadTimeout and KeepAliveTimeout correlated in Http11 Connector?
Summary: Why is disableUploadTimeout and KeepAliveTimeout correlated in Http11 Connector?
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 6.0.18
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2009-02-04 08:28 UTC by Doug Drechsel
Modified: 2009-03-06 07:21 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Doug Drechsel 2009-02-04 08:28:34 UTC
In Http11Processor.java

        while (started && !error && keepAlive) {

            // Parsing the request header
            try {
                if (!disableUploadTimeout && keptAlive) {
                    if (keepAliveTimeout > 0) {
                    else if (soTimeout > 0) {
                keptAlive = true;
                if (!disableUploadTimeout) {

disableUploadTimeout  - This flag allows the servlet container to use a different, longer connection timeout while a servlet is being executed, which in the end allows either the servlet a longer amount of time to complete its execution, or a longer timeout during data upload. If not specified, this attribute is set to "true".

The code above is waiting on a new Http Request and precedes the servlet processing logic.  It seems odd to me that I must set disableTimeout to false to get my keepAliveTimeout set.  

To set keepalivetimout, I must implicitely enable upload timeout whether I need it or not.  It seems to me that the disableTimeout is unneccessary in the following line

if (!disableUploadTimeout && keptAlive) {

Do you agree with this?

Thanks for the insight
Comment 1 Mark Thomas 2009-02-13 08:19:46 UTC
Looks reasonable to me. I have made the change in trunk and proposed it for 6.0.x. There is always a chance, particularly with the connector code, that I have missed a use case that explains why this is so. If that is the case, I am sure one of my fellow committers will point it out.
Comment 2 Doug Drechsel 2009-02-13 14:42:03 UTC
Hi Mark,

Thanks.  I agree with your assessment of unintended consequences. The location in such well exercised code does make one pause.  I am a newbie to this process. Do you have information as to how I can look at the modification in the trunk?

Comment 3 Mark Thomas 2009-02-14 11:57:13 UTC
Best to keep an eye on the tomcat dev list. Details here: http://tomcat.apache.org/lists.html

If you aren't already subscribed to the dev list, the commit message an be found in one of the many archives such as http://markmail.org/message/f744kl4i6bkruh5i
Comment 4 Mark Thomas 2009-03-06 07:21:53 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.