[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599676#comment-13599676
]
Alan M. Carroll commented on TS-1496:
-------------------------------------
I have attached a patch which works in preliminary testing. I plan to continue
testing and if successful commit this to trunk.
This patch should work in all cases, for any transform. It should also handle
blind tunnels and cache hits. It works at a tunnel level so that it limits the
total buffered data per tunnel flow (normally one). When the buffered data
exceeds the high water mark, the server side is stalled out until the data is
less than the low water mark at which point the server connection is resumed.
To enable this, use
proxy.config.http.flow_control.enabled INT 1
You can set the marks with
proxy.config.http.flow_control.high_water_mark INT <value>
proxy.config.http.flow_control.low_water_mark INT <value>
This won't work if the low value is bigger than the high value. If enabled but
the values aren't set 64K is used. These values (including flow control enable)
are also overridable per transaction, use TSHttpTxnConfigIntSet. This needs to
be done before connecting to the origin server. It should be possible, if
useful, to adjust the values dynamically.
This is based on a private fix I did for 3.2, although I think this version is
much improved over that in performance, especially in the accuracy of the
buffered data size (the previous version still had some initial bloom problems,
but this one in my testing always buffered within 48K of the target).
> Traffic Server with null-transform buffering large responses when client
> connection slow
> ----------------------------------------------------------------------------------------
>
> Key: TS-1496
> URL: https://issues.apache.org/jira/browse/TS-1496
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 3.2.0
> Environment: Red Hat 6.3
> Reporter: snf
> Assignee: Alan M. Carroll
> Fix For: 3.3.4
>
> Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
>
>
> Scenario: Traffic Server started with the null-transform plugin. The link
> between the client and Traffic Server is slower than the link between the
> Traffic Server and the Origin Server.
> Affect: If the client requests a large file from the Origin Server, the
> whole file can be transmitted to, and buffered by, Traffic Server before
> content is released to the client. This is a bigger issue if a large number
> of clients request large files then the Traffic Server could end up buffering
> very large amounts of content.
> Expected behaviour: The Traffic Server should not download all the content
> from the Origin Server. Instead, if the client is slow receiving from
> Traffic Server, then Traffic Server should be slow receiving from the Origin
> Server. Traffic Server should facilitate end to end flow control between
> client and Origin Server.
> Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
> the client machine.
> Possible related area in the Traffic Server code: The following comment
> appears in proxy/http/Httptunnel.cc
> 48 static void
> 49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
> 50 {
> 51
> 52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
> 53 // is 1GB, we will currently buffer the whole thing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
