[
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195302#comment-13195302
]
Wilson Ho commented on TS-1094:
-------------------------------
What I did was to create a file of URLs ... the same one repeated 512 times.
And then use the command :
cat <url_file> | xargs curl -m 25 -H "DummyHdr: xxxxx" -s -S > /dev/null
The exact URL I used probably won't work for you. You could use the -H flag to
create a dummy header to adjust the total header size. The 25 second time out
is to force curl to close connection when TS hangs, and generates the error
message
curl: (28) Operation timed out with 0 out of -1 bytes received
This way I could tell easily if TS hangs.
The header size must be exact. If my speculation is correct, that's how you
end up with a total size of 1 off the 4KB boundary. In theory, there could be
many other possible header sizes that could reproduce this problem. But if you
look closer, most values of (N x 4096) + 1 don't factorize into nice values
within the range of a normal header size. That's why this bug is so hard to
reproduce.
I'd appreciate if you could point me to the general direction in the source
code where request headers are stored/processed. We have a particular
application that keeps hitting this bug and I'm eager to patch our code. Or if
this bug has been fixed in new releases, please let me know, too! Thanks much!
> 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
