On Wed, Sep 12, 2012 at 7:32 PM, Phil Sorber <sor...@apache.org> wrote: > I opened up a ticket for #1 if you wanted to add anything to it. > > https://issues.apache.org/jira/browse/TS-1463
Thanks. I will update that with more comments > > On Wed, Sep 12, 2012 at 10:04 PM, Phil Sorber <sor...@apache.org> wrote: >> On Wed, Sep 12, 2012 at 8:48 PM, Shu Kit Chan <chanshu...@gmail.com> wrote: >>> Some updates for #1 after some more debugging. >>> >>> I was wrong on cache URL being locked. There is no lock or connection >>> collapse yet. Those subsequent requests for the same resources are >>> just TCP_MISS, causing extra request to origin server. It is still a >>> problem, though, because I expect a stale response for these >>> subsequent requests before the origin responds. >> >> Hmm, that's interesting. I agree that is a problem and I will have to >> look into this further to see how it can be solved. If you have some >> ideas or a patch I would be very interested in them. >> >>> >>> Thanks >>> >>> Kit >>> >>> On Wed, Sep 12, 2012 at 9:31 AM, Shu Kit Chan <chanshu...@gmail.com> wrote: >>>> Hi, >>>> >>>> I am trying this plugin out >>>> (https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861) >>>> and I have a few concerns >>>> >>>> 1) Let's assume that my origin server becomes slow and takes 10 >>>> seconds to respond after a while. Initially the origin server response >>>> is fast and cachable (e.g. "Cache-Control: max-age=30, >>>> stale-while-revalidate=300, public") and a cached copy is in the ATS >>>> cache. When the origin server becomes slow and the ATS cache copy >>>> expires, I assume the plugin should be able to return stale response >>>> from ATS and issue an async call to the origin server for the content. >>>> It will continues to give out stale responses from all other requests >>>> of this resource until the origin server comes back 10 seconds later >>>> with the response and cached properly in ATS. >>>> >>>> However, I don't think the plugin is doing it this way. The async call >>>> is made in a normal way and thus the cache URL is locked (according to >>>> this diagram - >>>> http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html). >>>> Subsequent requests to the same resource will get a cache miss and >>>> will be blocked till the origin server comes back with a response 10 >>>> seconds later. So in reality, what happened is that once a resource is >>>> expired, the first request for this resource will return with a stale >>>> copy and all subsequent request for this resource will be blocked till >>>> the origin server responds >>>> >>>> 2) Also, according to TS-998 >>>> (https://issues.apache.org/jira/browse/TS-998) , Wouldn't >>>> TSHttpHdrPrint() be causing trouble for the rfc5861 plugin? >>>> I can imagine that it will probably work when pristine_host_hdr is 0, >>>> though. We might be able to construct the async request using >>>> TSMimeHdrPrint() and construct the request line with previously saved >>>> variables. >>>> >> >> This is not a problem because we use TSHttpHdrClone() in the >> TS_HTTP_READ_REQUEST_HDR_HOOK before TS-998 bites us. This isn't ideal >> because it makes a copy of every single request, but it is the only >> work around I know of. >> Thanks for the explanation. >>>> 3) "troot" is a variable used to remember what URL is being called >>>> asynchronously right now. So a subsequent request to ATS will not >>>> generate extra async call of the same URL. But URL is only part of >>>> cache key. Some request headers can be part of the cache key based on >>>> the "Vary" response header. >>>> >> >> Not sure I understand this case. We already did the cache lookup and >> get back a STALE result so we want to do a fresh lookup to the origin >> and don't have a 'Vary' response header to to account for. The intent of >> troot >> isn't to lock the cache key, just the URL so we don't do multiple >> requests. If I have missed some case here we can definitely make a >> change to account for it. >> Here is an example The 2 requests below have the same URL but different cache entry in ATS if www.example.com is resolving to an ATS server and the response has a "Vary: Accept-Encoding" response header curl 'http://www.example.com/' curl --compressed 'http://www.example.com/ Now assume that both cache copies expires in ATS. Now if we run the first curl, it will result in an async call. And the second curl will not result in an async call until the the first curl is finished. Is this what's going to happen? If it is, is it bad. I am thinking it is definitely not disastrous, more like a bit undesirable. >>>> Thanks. >>>> >>>> Kit >> >> Thanks for the feedback. I'd like to get all the loose ends tied up and >> see this plugin get some good usage.
