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. >> 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. >> 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.
