You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (JIRA)" <ji...@apache.org> on 2015/12/16 16:09:46 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 ]

Alan M. Carroll updated TS-2761:
--------------------------------
    Fix Version/s:     (was: 6.1.0)
                   7.0.0

> 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
>            Assignee: Alan M. Carroll
>             Fix For: 7.0.0
>
>
> 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.3.4#6332)