I opened up a ticket for #1 if you wanted to add anything to it. https://issues.apache.org/jira/browse/TS-1463
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. > >>> 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.
