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