Bug 55160

Summary: NIO connectionUploadTimeout can't work
Product: Tomcat 7 Reporter: Roger Wang <jmwmj208>
Component: ConnectorsAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal CC: kubi0106
Priority: P2    
Version: 7.0.30   
Target Milestone: ---   
Hardware: PC   
OS: All   

Description Roger Wang 2013-06-29 21:35:09 UTC
when i configure disableUploadTimeout="false" and connectionTimeout="20000" ,connectionUploadTimeout="30000" .
I found the connectionUploadTimeout doesn't work, because the code in internalNioInputBuffer.readSocket():
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
try {
                NioEndpoint.KeyAttachment att = (NioEndpoint.KeyAttachment)socket.getAttachment(false);
                if ( att == null ) throw new IOException("Key must be cancelled.");
                nRead = pool.read(socket.getBufHandler().getReadBuffer(),socket,selector,att.getTimeout());
            } catch ( EOFException eof ) {
                nRead = -1;
            } finally { 
                if ( selector != null ) pool.put(selector);
            }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
att.getTimeout() is the connectionTimeout ,not the connectionUploadTimeout.
so , in NioBlockingSelector.read(), the readTimeout is connectionTimeout
Comment 1 Mark Thomas 2013-07-01 14:29:00 UTC
Thanks for the report.

This has been fixed in trunk and 7.0.x and will be included in 7.0.42 onwards.
Comment 2 Garrison Kubis 2020-10-09 23:10:38 UTC
This bug has resurfaced.

The fix https://github.com/apache/tomcat/commit/dc08904d6f515d90e49f24bf635c955156ce4cb0 was reverted 4 years later by https://github.com/apache/tomcat/commit/c8ea5646a66d7b31974f9594787961a44019c045


The read timeout is once again the connectionTimeout and not the connectionUploadTimeout.
Comment 3 Mark Thomas 2020-10-15 15:59:08 UTC
Confirmed (with a unit test) that this is currently broken for NIO on 7.0.x. Later versions are not affected.
Comment 4 Mark Thomas 2020-10-15 16:51:31 UTC
Re-fixed in 7.0.x for 7.0.107 onwards.
Comment 5 Garrison Kubis 2020-10-22 18:58:53 UTC
Thanks Mark, I don't see the 7.0.107 tag yet.