[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197364#comment-13197364 ]
Leif Hedstrom commented on TS-1094: ----------------------------------- Yeah, it needs a different fix. But, glad to hear it works for you, means at least I'm on the right track. Unfortunately $work is getting in the way right now, but I'll work more on this soon (and Alan promised to help too, since it's his fault ;). > 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 > Assignee: Leif Hedstrom > Priority: Blocker > Fix For: 3.1.2 > > > 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