[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956160#comment-13956160
]
Faysal Banna commented on TS-2632:
----------------------------------
Well.
look at the scenario. Youtube Videos .. they are cache-able. most of the
downloads from download.com or cnet.com, those are also cache-able, vimeo
videos, Android apps .. to count its almost uncountable. and they all generate
a session based signature with certain fixed ID and serial that we use with the
combination along in cacheurl plugin (cache-key) to store them and thus if
range request is being applied to those objects and sites this becomes urgent
to cache them in background doing a full none range request.
i don't know about the locking mechanism you previously been talking about all
i know is that it becomes crucial to serve cache content for range requests
these days.
take for instance windows updates even requesting a full file they almost
always send a range request range=0-xxxx where xxxx is the full size of the
file. and reply comes in with 206 which ATS at current implementation doesn't
cache it. thats why also its very crucial to have this plugin.
i can think of tons of scenarios that this becomes efficient enough. its just
needs adjusting as have more control per request or per time base in such a way
that off peak hours we can do the filling or what url/uri can be worked with.
also take into consideration if it can be managed as per remap_plugin that
would be great. with a logging option as to what is being processed as a
background-fetch.
One thing i have to mention also is the ability to adjust at what rate the
background filling would go. so that we won't be overusing our origin bandwidth
serving 100's of background-fetch objects at max speed (windows updates for
example or maybe apple ios7 ) that may choke our bandwidth and prevent us from
serving other requests at ease.
much regards
> Range request will always lock object in cache, even thought it's rarely
> cacheable
> ----------------------------------------------------------------------------------
>
> Key: TS-2632
> URL: https://issues.apache.org/jira/browse/TS-2632
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
>
> Right now, if a client sends a Range: request, we still lock the URL in the
> cache, under the assumption that it will be written to. Since we don't
> support partial objects, in almost all cases, we'll not write the object and
> therefore release the object.
> I suggest we change this such that we never try to write lock a URL in the
> presence of a Range: header in the client request. This will allow other
> requests to go to origin faster, and better yet, it allows a request without
> a Range: header to properly lock the URL for writing. This turns out to be
> important for implementing e.g. "background filling" as a plugin.
> There is one use case where this might be useful; If the origin does not
> respond with a 206 (partial object), we can now cache the full object.
> However, this is a pretty rare case, and for someone to support this, all you
> have to do is to remove the Range: header on the request.
> I'm opening up this bug right now for discussion, if anyone have any concerns
> about this change, please let me know. It is an "incompatible" change,
> without configuration options, but that should be ok for the v5.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
