Bug 50906 - Chunked encoding not terminated with native library
Summary: Chunked encoding not terminated with native library
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 7.0.8
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-09 17:13 UTC by Chris
Modified: 2011-03-13 20:31 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris 2011-03-09 17:13:43 UTC
I'm using Tomcat 7.0.8 on Ubuntu 10.10.

When using the APR based Tomcat Native Library (libtcnative), responses from Tomcat are being sent with a chunked encoding, but the "0" terminating the chunked response isn't sent until exactly 1 minute later.

The response is being written to an org.apache.catalina.connector.CoyoteOutputStream. The following calls are made:
out.write(resp);
out.flush();
out.close();

If I just remove the libtcnative-1.so, so that Tomcat loads without using it, then the response still uses chunked encoding, but the terminating "0" is sent immediately, with the rest of the response.
Comment 1 Chris 2011-03-10 12:50:01 UTC
I'm including some additional info that I'd posted to the mailing list:

- I'm running with nginx in front of tomcat
- The 60 second timeout is happening in nginx and not tomcat
- Regardless of whether or not I'm using libtcnative, I don't see the terminating "0\r\n\r\n" being sent by tomcat to nginx
- When not using libtcnative, the connection is closed after writing the response; there's a FIN, in addition to ACK on the last TCP packet from tomcat. Nginx seems to use this to infer the end of the response and add the "0\r\n\r\n" to the reply sent to the client.
- When using libtcnative, there is no FIN on the last TCP ACK packet, and the connection stays open. One minute later nginx times out waiting for the response to complete and adds the "0\r\n\r\n" to the response to the client.
- I notice that if I use curl to make a request directly to tomcat (instead of going through nginx), then I do see the terminating "0\r\n\r\n". I still see a difference in that tomcat disconnects immediately after the reply when not using the native library.

Later I said...:
I've narrowed this down even further.

 As I mentioned below, the "0\r\n\r\n" was not being sent to nginx, although it was being sent to curl. The difference was that nginx was doing a GET HTTP/1.0, while curl was using HTTP/1.1. If I configure curl to use HTTP/1.0 then I get the same result: no "0\r\n\r\n" is sent.

So, to summarize:
- GET HTTP/1.0 results in no terminating "0\r\n\r\n" for the chunked response, regardless of whether libtcnative is being used.
- The difference when using libtcnative is that the connection isn't terminated after the response is sent.
Comment 2 Mark Thomas 2011-03-13 15:04:02 UTC
I have done some testing and I can't reproduce this. You'll need to provide the simplest possible web application (ideally a single Servlet) that demonstrates Tomcat sending chunked responses for an HTTP 1.0 request. Please include the source code.

Without a test case that demonstrates this bug, it will get resolved as WORKSFORME.
Comment 3 Chris 2011-03-13 20:31:09 UTC
After upgrading to 7.0.11 I'm no longer seeing the problem. This seems to be the relevant changelog entry:

"Fix issues that prevented asynchronous servlets from working when used with the HTTP APR connector on platforms that support TCP_DEFER_ACCEPT. (markt)"

The fact that the servlet was doing async processing was probably an important fact that I neglected to mention earlier.