[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195935#comment-13195935 ]
Leif Hedstrom commented on TS-1094: ----------------------------------- I'm not 100% sure (or even 90% sure), but can you try this patch (against trunk, but probably 3.1.0|1 would work too): {code} diff --git a/proxy/hdrs/MIME.cc b/proxy/hdrs/MIME.cc index d448421..0c4db0e 100644 --- a/proxy/hdrs/MIME.cc +++ b/proxy/hdrs/MIME.cc @@ -2461,7 +2461,6 @@ mime_scanner_get(MIMEScanner * S, } else if (data_size) { // Inside a field but more data is expected. Save what we've got. mime_scanner_append(S, *raw_input_s, data_size); - data_size = 0; // Don't append again. } } {code} This "fix" in its own doesn't make any sense, but it'd help to know if this eliminates (or changes) the problem for you in any way. > TS hangs after repeated requests from the same kept-alive connection > -------------------------------------------------------------------- > > Key: TS-1094 > URL: https://issues.apache.org/jira/browse/TS-1094 > Project: Traffic Server > Issue Type: Bug > Components: Core > Affects Versions: 3.1.0 > Environment: Oracle Enterprise Linux 5.5 64-bit > Reporter: Wilson Ho > Priority: Blocker > Fix For: 3.1.3 > > > When a client submits multiple requests while re-using the same keep-alived > connection, TS hangs. Usually, the client eventually times out, and at that > point TS will be "waken" up and forwards the request to the original server. > But by then it's too late and the client already closed connection. > In real life traffic, this bug is very hard to reproduce. But here is an > artificial test case. > First, make sure client-side keep alive is on. My test case uses HTTP (port > 80) GET. > Second, make sure the total header size of the requests is exactly 275 bytes, > including the carriage returns and line feeds. One byte more or less would > fail to reproduce the bug. > Third, repeatedly submit the same request through this keep-alived > connection. At exactly the 283rd iteration, TS hangs. Note that if the > client opens a new connection every time, TS works fine. > There is a second test case, where the header size is exactly 283 bytes, and > TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) > These magic numbers seem to suggest a memory buffer size (or allocation) > problem. I speculate that headers from repeated requests are placed in a > buffer (or a circular buffer?), and when the total hits a particular size, > some boundary conditions must have be violated and resulted in memory > corruption. > In real life traffic, each request typically has slightly different header > size, so it is really hard to hit this bug. I suspect there is a +/- 1 > calculation error in some buffer. > BTW, turning on/off caching does not make any difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira