[
https://issues.apache.org/jira/browse/TS-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3431:
------------------------------
Fix Version/s: sometime
> 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
> Priority: Minor
> Fix For: sometime
>
>
> 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)
