Nick Muerdter created TS-3431:
---------------------------------
Summary: 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
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)
