[ https://issues.apache.org/jira/browse/TS-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Muerdter updated TS-3431: ------------------------------ Affects Version/s: 5.2.0 > enable_read_while_writer delays requests for mis-matched HTTP methods > --------------------------------------------------------------------- > > Key: TS-3431 > URL: https://issues.apache.org/jira/browse/TS-3431 > Project: Traffic Server > Issue Type: Bug > Affects Versions: 5.2.0 > Reporter: Nick Muerdter > > 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: > {code} > var http = require("http"); > http.createServer(function(request, response) { > setTimeout(function() { > response.writeHead(200); > response.write('example response'); > response.end(); > }, 10000); > }).listen(3000); > {code} > I then took a default TrafficServer 5.2.0 install with the only change being > to use this backend in remap.config: > {code} > map / http://127.0.0.1:3000/ > {code} > 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): > {code} > $ 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 > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)