On May 31, 2013, at 1:32 AM, 오재경 <[email protected]> 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: 오재경 [mailto:[email protected]] > Sent: Thursday, May 30, 2013 4:06 PM > To: [email protected] > 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, CACHE_EVENT_OPEN_WRITE_FAILED]". > > 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.
