https://bz.apache.org/bugzilla/show_bug.cgi?id=58583
Bug ID: 58583
Summary: HTTP client fails to close connection, violates RFC
2616
Product: JMeter
Version: 2.13
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: HTTP
Assignee: [email protected]
Reporter: [email protected]
Created attachment 33256
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33256&action=edit
The JMeter configuration + wireshark capture of network traffic
Hi,
I have an HTTP server I am testing. The particular test pattern has the
following behaviour (where some details are excluded for brevity)
client> GET /path/to/file [sent to server.example.org]
server> 302 Found [Location: http://other.example.org:port/path/to/file]
client> GET /path/to/file [sent to other.example.org]
server> 200 OK [with the entity as the response body]
That operation is repeated several times (using a Loop Controller), but the
Thread Group has a single thread, so the requests are serialised. In addition,
I placed a one second delay in the loop (using a Constant Timer), so there is
at least a one second delay between successive GET requests to
other.example.org.
I've configured JMeter NOT to reuse connections (the "Use KeepAlive" checkbox
is cleared). This means that the client includes the `Connection: close`
header in the requests. Both server.example.org and other.example.org close
the connection after sending the response.
The other point to note is that the port number of other.example.org is always
the same.
Using wireshark, I have observed that JMeter never reacts to other.example.org
sending the FIN packet: there is a corresponding ACK from the client (generated
by the OS), but no FIN. This leaves the TCP connection in the half-closed
state: CLOSE_WAIT.
This is in contrast with JMeter's behaviour with server.example.org, where it
does react to FIN and sends its own FIN, fully closing the TCP connection.
I have also observed JMeter attempting to reuse these half-closed connections
and send a GET request on a CLOSE_WAIT connection. Since the server has closed
both ends of the socket, the server OS replies with a RST. This forcefully
closes the connection.
JMeter appears to have two modes of operation: one where it does not reuse
connections and one where it does.
When JMeter is not attempting to reuse connections with other.example.org,
fresh connections are made to the server for each request. This is despite the
existing connection not being closed on the client. When operating like this,
all GET requests to other.example.org succeed.
When attempting to reuse connections, the client sends a GET request on an
existing connection (which is in CLOSE_WAIT state). The server's OS responds
with a RST. This RST results in the next iteration's GET request to
other.example.org creating a fresh TCP connection. The subsequent GET request
succeeds; however, it includes the "Connection: close" header, with the server
closing the connection. In the next iteration, the GET request to
other.example.org will then fail (RST). Thus, when attempting to reuse
connections, the GET requests to other.example.org will alternate between
succeeding and failing.
I have observed JMeter when running the Test Plan several times. In some cases
JMeter initially does not attempt to reuse connections and, after several
iterations, it starts attempting to reuse connections. For some Test Plan
runs, JMeter always attempts to reuse connections. However, once JMeter has
started attempting to reuse connections, I have not seen it revert to not
attempting to reuse connections. I haven't been able to determine what factors
control this behaviour.
Apart from being undesirable behaviour, this is clearly a violation of RFC
2616: where section 8.1.2 "Once a close has been signaled, the client MUST NOT
send any more requests on that connection."
I'd be grateful if someone could investigate. I have attached the JMeter
configuration and a copy of the network traffic (where both client,
server.example.org and other.example.org is 'localhost').
Cheers,
Paul.
--
You are receiving this mail because:
You are the assignee for the bug.
