You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2014/05/01 04:37:16 UTC
[jira] [Updated] (TS-2761) Weird behavior of read-while-write
[ https://issues.apache.org/jira/browse/TS-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-2761:
------------------------------
Fix Version/s: sometime
> Weird behavior of read-while-write
> -----------------------------------
>
> Key: TS-2761
> URL: https://issues.apache.org/jira/browse/TS-2761
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Performance, Quality
> Reporter: Faysal Banna
> Fix For: sometime
>
>
> Hello.
> There is an issue with read-while-write stuff in ATS that is explained as follows :
> If a client starts a file download lets say 10MB file, and after couple of seconds another client coincidentally requests this same file.
> When client1 terminates the file download for any reason, supposedly client2 should take over and continue the download till it gets saved, yet
> whats happening here is that client2 gets connection interrupted after whatever is configured in proxy.config.http.background_fill_active_timeout.
> And then re-initiates another request in a Range header and thus the file is never saved.
> isn't this unpleasant to deal with read_while_revalidate and cache saving process ?
> Imagine a 200MB windows update file, defenetly we need that saved in the cache.
> look at the situation where You have 10 clients watching a movie that am happy that my server is caching it .. suddenly first client who initially requested the movie aborts all the remaining 9 clients would get interrupted and each one requests a new file with range header
> and thus now i shall be getting 9 different requests for the same movie with range header which is never cached and thus instead of saving bandwidth you shall be consuming bandwidth for the same file(object) 9 times.
> In my opinion background fill should take over only if no one is consuming the connection(request) anymore, and thus it may timeout with whatever timeout it holds in config.
> Much Regards
--
This message was sent by Atlassian JIRA
(v6.2#6252)