[jira] [Updated] (TS-1094) TS hangs after repeated requests from the same kept-alive connection

["Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-1094:
------------------------------

    Fix Version/s: 3.1.3

Heh, that's one hell of a bug, 275 bytes exactly, eh?
                
> 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