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

enable_read_while_writer delays requests for mis-matched HTTP methods

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.2.0
    • Fix Version/s: sometime
    • Component/s: Core
    • Labels:
      None

      Description

      If enable_read_while_writer is enabled (which it is by default), then a GET request can hold up the processing of a POST request to the same URL endpoint. Since the POST request is fundamentally different, it doesn't seem like the POST request should be waiting for the fulfillment of the GET request before processing.

      An example might be the easiest way to demonstrate this: Let's say you have a backend that has both a GET and POST endpoint at the same URL. Each of these requests takes 10 seconds to complete. If you make the GET request first, and then quickly follow it by the POST request to the same URL, then the GET request will complete in 10 seconds, while the POST request will take 20 seconds (since it first waits 10 seconds for the GET request to complete, then apparently realizes it can't actually use the cache, and then proceeds to the POST request which takes another 10 seconds). However, it's worth noting that if you make the requests in the opposite order (POST first, and then GET), then there are no delays.

      Here's some example scripts to demonstrate this. Here's a node.js backend that will respond to both GET and POST requests at the same URL and take 10 seconds:

      var http = require("http");
      http.createServer(function(request, response) {
        setTimeout(function() {
          response.writeHead(200);
          response.write('example response');
          response.end();
        }, 10000);
      }).listen(3000);
      

      I then took a default TrafficServer 5.2.0 install with the only change being to use this backend in remap.config:

      map / http://127.0.0.1:3000/
      

      Here's the output from a GET request with a POST request following shortly after and happening in parallel (note the POST request takes nearly 20 seconds to complete):

      $ time curl -v "http://127.0.0.1:8080/"
      * About to connect() to 127.0.0.1 port 8080 (#0)
      *   Trying 127.0.0.1... connected
      * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
      > GET / HTTP/1.1
      > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
      > Host: 127.0.0.1:8080
      > Accept: */*
      > 
      < HTTP/1.1 200 OK
      < Date: Sun, 08 Mar 2015 21:49:36 GMT
      < Age: 10
      < Transfer-Encoding: chunked
      < Connection: keep-alive
      < Server: ATS/5.2.0
      < 
      * Connection #0 to host 127.0.0.1 left intact
      * Closing connection #0
      example response
      real	0m10.017s
      user	0m0.005s
      sys	0m0.002s
      
      
      $ time curl --data "foo=bar" -v "http://127.0.0.1:8080/"
      * About to connect() to 127.0.0.1 port 8080 (#0)
      *   Trying 127.0.0.1... connected
      * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
      > POST / HTTP/1.1
      > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
      > Host: 127.0.0.1:8080
      > Accept: */*
      > Content-Length: 7
      > Content-Type: application/x-www-form-urlencoded
      > 
      < HTTP/1.1 200 OK
      < Date: Sun, 08 Mar 2015 21:49:46 GMT
      < Age: 10
      < Transfer-Encoding: chunked
      < Connection: keep-alive
      < Server: ATS/5.2.0
      < 
      * Connection #0 to host 127.0.0.1 left intact
      * Closing connection #0
      example response
      real	0m19.531s
      user	0m0.004s
      sys	0m0.002s
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                nickm Nick Muerdter
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: