[
https://issues.apache.org/jira/browse/TS-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143348#comment-14143348
]
Zhao Yongming edited comment on TS-2314 at 9/22/14 4:10 PM:
------------------------------------------------------------
yeah, I think your suggestion is great. and the current rww lack of support for
many cases besides this case, for example:
1, how long a reader in waiting should wait for?
in this case, the answer sounds like not at all, but use as much downloaded
data as possible
2, should we enable the rww for a file as big as 5G?
for example I'd like to make a limited usage with relatively small files
such as <30m, due to the origin site is far away from the edge site.
3, should we consider on the patial feature in the
https://cwiki.apache.org/confluence/display/TS/Partial+Object+Caching ?
4, well, if it is a low speed user that triggered the cache storing, will it be
a speed problem for others readers that waiting?
well, that are some of the issues we thinking on rww, I just want rww get more
loves :D
was (Author: zym):
yeah, I think your suggestion is great. and the current rww lack of support for
many cases besides this case, for example:
1, how long should a reader in waiting should wait for?
in this case, the answer sounds like not at all, but use as much downloaded
data as possible
2, should we enable the rww for a file as big as 5G?
for example I'd like to make a limited usage with relatively small files
such as <30m, due to the origin site is far away from the edge site.
3, should we consider on the patial feature in the
https://cwiki.apache.org/confluence/display/TS/Partial+Object+Caching ?
4, well, if it is a low speed user that triggered the cache storing, will it be
a speed problem for others readers that waiting?
well, that are some of the issues we thinking on rww, I just want rww get more
loves :D
> New config to allow unsatifiable Range: request to go straight to Origin
> ------------------------------------------------------------------------
>
> Key: TS-2314
> URL: https://issues.apache.org/jira/browse/TS-2314
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: jaekyung oh
> Labels: range
> Attachments: TS-2314.diff
>
>
> Basically read_while_writer works fine when ATS handles normal file.
> In progressive download and playback of mp4 in which moov atom is placed at
> the end of the file, ATS makes and returns wrong response for range request
> from unfulfilled cache when read_while_writer is 1.
> In origin, apache has h264 streaming module. Everything is ok whether the
> moov atom is placed at the beginning of the file or not in origin except a
> range request happens with read_while_writer.
> Mostly our customer’s contents placed moov atom at the end of the file and in
> the case movie player stops playing when it seek somewhere in the movie.
> to check if read_while_writer works fine,
> 1. prepare a mp4 file whose moov atom is placed at the end of the file.
> 2. curl --range xxxx-xxxx http://www.test.com/mp4/test.mp4 1>
> no_cache_from_origin
> 3. wget http://www.test.com/mp4/test.mp4
> 4. right after wget, execute “curl --range xxxx-xxxx
> http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal
> (the point is sending range request while ATS is still downloading)
> 5. after wget gets done, curl --range xxxx-xxxx
> http://www.test.com/mp4/test.mp4 1> from_cache
> 6. you can check compare those files by bindiff.
> The response from origin(no_cache_from_origin) for the range request is
> exactly same to from_cache resulted from #5's range request. but
> from_read_while_writer from #4 is totally different from others.
> i think a range request should be forwarded to origin server if it can’t find
> the content with the offset in cache even if the read_while_writer is on,
> instead ATS makes(from where?) and sends wrong response. (In squid.log it
> indicates TCP_HIT)
> That’s why a movie player stops when it seeks right after the movie starts.
> Well. we turned off read_while_writer and movie play is ok but the problems
> is read_while_writer is global options. we can’t set it differently for each
> remap entry by conf_remap.
> So the downloading of Big file(not mp4 file) gives overhead to origin server
> because read_while_writer is off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
