I found a tricky solution.
Just let background_fill_completed work. That is the plugin disconnect right after get some from origin. 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.
