[
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197969#comment-13197969
]
Leif Hedstrom commented on TS-1094:
-----------------------------------
Cool, I'll test this in a bit. Question: Do we still need that second change
from TS-466, we reorders the call to mime_scanner_append() ?
> 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
>
> Attachments: ts-1094.diff
>
>
> 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
