[ 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