[jira] Updated: (TS-316) Add a limit to the number of requests through a single KeepAlive connection

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

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

Leif Hedstrom updated TS-316:
-----------------------------

    Fix Version/s: 2.3.0

> Add a limit to the number of requests through a single KeepAlive connection 
> ----------------------------------------------------------------------------
>
>                 Key: TS-316
>                 URL: https://issues.apache.org/jira/browse/TS-316
>             Project: Traffic Server
>          Issue Type: Improvement
>            Reporter: Miles Libbey
>            Priority: Minor
>             Fix For: 2.3.0
>
>
> (was yahoo bug 1953368)
> Original description
> by Daniel Weaver  22 months ago at 2008-05-22 14:50
> This is a request to support a mechanism equivalent to Apache's MaxKeepAliveRequests directive. http://httpd.apache.org/docs/1.3/mod/core.html#maxkeepaliverequests
> Basically, after the specified number of requests come through, a "Connection: close" header is sent back to
> the client to break the connection. This is useful because eternal Keep-Alive essentially thwarts load balancers, and
> can result in very uneven traffic over time (especially when restarting a TS -- all connections are broken when it
> shuts down, and then when it restarts it gets no new connections, because all the clients have Keep-Alive sessions with
> the other TS's that were behind the vip).
> This conversation started in bug 1950760; see it for additional context. Sherpa may experiment with inserting
> "Connection: close" headers randomly in its response plugin in the meantime.
> 		
>  
> Comment 1
>  by Chuck Neerdaels  22 months ago at 2008-05-22 15:11:32
> If it's added to the general TS path it'll break stuff. For instance
> pipelining - if a client shoots 6 requests and you do a shutdown after
> they get a response for 3, they have to unwind and reissue the requests.
> Yes, clients could be written to deal with this, but there's a general
> assumption that if you accepted and read the request, you intend to
> answer it - barring something catastrophic. 
> The 1.1 spec is pretty ambiguous here. Closing connections when there's
> a timeout generally flies, but inserting one midstream while under load
> is going to backfire. Proxies just don't do that - even though servers
> and clients can.
> chuck
>  
> Comment 2
>  by Daniel Weaver  22 months ago at 2008-05-22 15:56:14
> Yeah... not a lot of commentary out there on the interaction between pipelining and connection closing. I did find this
> article that emphasizes, "Servers must therefore close each half of the connection independently."
> http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html#After_Tuning

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.