[
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195910#comment-13195910
]
Leif Hedstrom commented on TS-1094:
-----------------------------------
Yeah, I ended up doing something similar too (except I used ab). I can
reproduce it with (in my case)
{code}
ab -c 1 -k -n 247 -H "Foo:
11111111111111111111111111112333333333333333333333333333333333333333333333"
http://loki.ogre.com/bench/100.bmp
{code}
Turning on slow log, it clearly indicates that it's hung in reading the request
header (which is no surprise). I also tested it with a single net-thread, and
while "ab" is hanging, the server still responds to other requests on that
thread. So, it's not blocking the thread.
What's weird is that I tested the above ab from "localhost" (linux) and also
from another Linux box (over GigE), and they both hang. But from my Mac, I'm
not able to reproduce it (tested various other header lengths etc.).
> 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
