Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-2761

Weird behavior of read-while-write



    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 7.2.0
    • Component/s: Cache, Performance
    • Labels:


      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


          Issue Links



              • Assignee:
                amc Alan M. Carroll
                degreane Faysal Banna
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: