| Summary: | NIO connectionUploadTimeout can't work | ||
|---|---|---|---|
| Product: | Tomcat 7 | Reporter: | Roger Wang <jmwmj208> |
| Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kubi0106 |
| Priority: | P2 | ||
| Version: | 7.0.30 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
Thanks for the report. This has been fixed in trunk and 7.0.x and will be included in 7.0.42 onwards. 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. Confirmed (with a unit test) that this is currently broken for NIO on 7.0.x. Later versions are not affected. Re-fixed in 7.0.x for 7.0.107 onwards. Thanks Mark, I don't see the 7.0.107 tag yet. |
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