jgaalen commented on issue #6330: URL: https://github.com/apache/jmeter/issues/6330#issuecomment-2621285050
> [@jgaalen](https://github.com/jgaalen) , please refer to RFCs or the public documentation. Otherwise it is hard to tell where all your conclusions come from. Many parts of your messages violate or contradict RFCs and Java documentation. Perhaps screenshots make it more obvious what is going on. I've made a test case, with a simple nginx and a keep-alive timeout setting of 2 seconds. Then running a simple jmeter thread with 1 request, then waits 4 seconds, then does request 2. We get the following error:  This is a tcpdump which shows what is going on:  Here we can see it does the request, Then 2 seconds later, the webserver sends the FIN to close the socket. JMeter/client only responds with an ACK. At this moment, the connection is in CLOSE_WAIT state at the client (JMeter), and in FIN_WAIT_2 state at the server (nginx). After this, it does nothing. 2 seconds later (4 seconds after previous request), we can see client/jmeter tries to send the next request on the existing socket. The server (nginx) doesn't respond with an HTTP-200 or any other valid http data response, but it sends the FIN again (I've said RST before, this was false, it sends the FIN). After this, JMeter throws the Non HTTP response code error You cannot argue this is good and expected behaviour from JMeter. It should simply not try to send the request on this half-closed socket. Even tho, it is technically allowed to keep the socket in a half-closed/open state, it should not send a new request over this as it would lead to obvious errors which are not realistic.  This screenshots shows the behaviour from a browser (firefox). You can see that 2s after the response, the server closes the connection, but immediately, firefox (client) closes the connection on its behave as well, clearing the socket on both ends.  This screenshot shows the behaviour when we wait 6 seconds rather than 4 seconds (passing the 4900ms of default httpclient4.validate_after_inactivity), we can see better behaviour. Before it tries to send the request, it first closes the connection on the client side as well (notifying the server with a FIN/ACK) and creates a new connection. workaround is to set httpclient4.validate_after_inactivity maybe to 1ms so it always evaluates if the socket is in a half-closed state and acts how it should -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
