[
https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023071#comment-13023071
]
Eric Balsa commented on TS-475:
-------------------------------
VJ, yes, you can take it or we can collaborate to finish it up. I would say my
local copy is 80% there but needs some work and i've been stupid busy with work
& baby.
Here's what i've done so far: John (and me to a small extent) got
CacheVC::do_io_pread() working on the cache so we can now (theoretically,
though barely tested) seek to arbitrary locations on a cache object.
The SM currently uses a transform for handling Range requests. The logic is
something like:
* lookup full object from cache
* check for range header
* setup a transform hook to be handled during HttpTunnel
...
* do_io_read() on the object and hand that vio to the transform hook
* transform the object by re-reading certain headers, parse the C-L & Range
headers, and do Range: transform work
What I was working on was changing the model to store the Range: logic in the
SM rather than inside the Transform (RangeTransform objects).
In HttpSM::do_range_setup_if_necessary() i bounce into a couple other fns to
parse the Range: header similar to what the transform does now (almost 1:1 with
RangeTransform::XXXX and setup various Range settings in the t_state)
Then, when we read from the cache, we can simply do a do_io_pread() with the
proper known offsets.
Problems:
1) This only handles the simple case of Range:bytes=1-10 but not the
complicated case of Range:bytes=1-10,70-80,100-500 . I think this would satisfy
90% of the uses cases (Leif thinks most clients don't do anything too crazy :)
). For the "complicated case", I still am using the transform (if # of "Ranges"
>1). Ideally, we should somehow handle this with only object::do_io_pread()s
but the issue, as I see it, is we are so far down in processing (at the point
where we tunnel the cache object to the client), that it would be difficult (I
think) to re-tunnel multiple partial "contents" (along with each added Range
content separator). Just a pita b/c you have work with the VIO, loop(read the
i-th range, add separators, i++), and finally, make sure you have the C-L
right. I'm sure it's doable, but I punted and figured I would just hand it to
the existing transform but then complicated Range: requests would still
do_io_read() the whole object.
2) My patch needs a ton of cleanup but IIRC (been a few weeks) I had it serving
the simple case without any transforms & using do_io_pread() along with the
right C-L (always a good thing), but i'll email it to you and you give give it
a whirl.
3) ...more
We can chat on IRC if you want to talk more about this.
--Eric
> HTTP SM should support efficient byte range requests
> ----------------------------------------------------
>
> Key: TS-475
> URL: https://issues.apache.org/jira/browse/TS-475
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Eric Balsa
> Priority: Critical
> Fix For: 2.1.9
>
>
> The cache has support for efficiently locate a particular range in the cached
> object, but the HTTP SM does not support this. In order to make Range:
> request efficient (particularly on large objects), the SM should support this
> new cache feature.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
