trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: why does a range request get in CACHE_EVENT_OPEN_WRITE?
Date Fri, 31 May 2013 22:54:36 GMT
On May 31, 2013, at 1:32 AM, 오재경 <> wrote:

> I found a tricky solution.
> Just let background_fill_completed work. That is the plugin disconnect right after get
some from origin.

This would be a great feature for core. It's not 100% of what people want from range requests,
but it's common enough and very helpful.

> Even if download happens a couple of times in stress test it’s better than the plugin
keeps downloading again and again.
> Thanks.
> From: 오재경 [] 
> Sent: Thursday, May 30, 2013 4:06 PM
> To:
> Subject: why does a range request get in CACHE_EVENT_OPEN_WRITE?
> Hi. how are you?
> I converted rfc5861 plugin to a plugin that triggers a download from origin server when
it gets cache miss about the range request.
> But the problem is background download hardly get cached at once. usually it gets cached
after 5~10 times background download.
> So i traced the full debug log of ATS.
> i found a range request also get in CACHE_EVENT_OPEN_WRITE, which finally comes to "[is_response_cacheable]
Partial content response - don't cache".
> Meanwhile the triggered full contents download fails to get "(http_cache) [41] [&HttpCacheSM::state_cache_open_write,
> That happens several times until background download get cached and gives heavy traffic
to origin server.
> Why does a range request get in CACHE_EVENT_OPEN_WRITE none the less it won't be cached?
> How can i force ATS to cache the background download at the first time? or is there any
way ATS have range request not get in CACHE_EVENT_OPEN_WRITE?
> Thanks in advance.
> P.S. i'm afraid it happens also in the case we use background_fill_completed option.
if there are many traffic i think ATS can't assure the background_fill will be cached at once
because of the cache open write lock.

View raw message