jgaalen commented on issue #6330: URL: https://github.com/apache/jmeter/issues/6330#issuecomment-2619298326
> > If the server closes an HTTP connection, jmeter should handle the closed connection immediately and not keeping it in CLOSE_WAIT state until the next request, which could also lead to "Non HTTP response" errors > > Well, could you please clarify why would you expect exactly this behavior? As far as I understand, It is pretty much fine for the "server" to close a connection while client could still send some data. > > In other words, it means "server is done sendings its bytes", however, it is fine for a TCP connection to be in half-closed state, and the client can still send data and the server could receive it. First of all, it is not fine for a tcp connection to be in half-closed state. The client can't send data where the server would receive it. At least not in a FIN_WAIT_2 / CLOSE_WAIT state, because this means the server is trying to shut down the socket, but the client didn't do it yet. If the client then sends a packet as if the connection would still be open, it would get a RST which is not fine. > > > Currently, when JMeter does an HTTP request and is in keep-alive state and server waits for the next request. If the server closes the connection after X-seconds and sends a FIN/ACK packet, JMeter does nothing. If the next request is done within 5 seconds after the FIN/ACK packet, it sets a "Non HTTP response message: : failed to respond" error immediately, because the socket is already in CLOSED state and can't pick up new packets. This results in this error. > > Well, this boils down to the expected outcome of your test. > > In practice, people use JMeter to simulate actual applications. So you should configure JMeter exactly the same as the application/microservice/browser you try to impersonate. > > For instance, if the application/microservice/browser does not expect the server to close a connection shortly, then the application would fall into the same issue of trying to send data over a broken connection. In other words, "Non HTTP response message: : failed to respond" surfaces a configuration error (assuming you've configured JMeter the same as your app). > > If the application performs connection re-validation, you should configure JMeter to do so. > > Does that make sense? You are right with simulating the clients behaviour. In most cases, the client you are simulating is either a browser or some kind of microservice doing API-calls. Either way, whenever the other end (server) sends a FIN/ACK packet, other client should simply respond with a FIN/ACK as well, so both ends can close the socket (similar to a SYN request, the other end has to respond with SYN/ACK to accept it or not). None of the browsers at least behave in a way, that after a FIN/ACK, they do nothing. They all accept the disconnect and are not trying to sent a new request over a half-closed socket. We can lower the idle time with httpclient4.validate_after_inactivity to avoid non http errors in jmeter, but actually either way, JMeter should instant close the connection on the client and respond so the server can fully remove the socket and not keep it in CLOSE_WAIT. Maybe there are clients that behave the way jmeter behaves, because they use the httpclient4/5 lib, but that would be very rare. > > > but doesn't resolve the high CLOSE_WAIT state taking unrealistic higher connections on jmeter clients and left FIN_WAIT_2 state on webservers > > If your webserver closes connections immediately while JMeter trying to keep them alive, I expect it might be the following: a) It might be a true configuration bug discovered by JMeter. In other words, you will have "many CLOSE_WAIT connections" in production if clients attempt to use keepalive while the server closes the connections early b) If the clients do not use keepalive in production, you should disable keepalives in JMeter as well > > WDYT? In a normal browser-webserver situation, or HTTP/1.1 default, keep-alive is the default and the server dictates when to close the connection, not the client. The client has no idea when (the keep alive time in the header could give it a hint, but it's just a hint). But when the server closes a connection, ie after 2 seconds which is what many webservers do, then we start being into an unrealistic situation already, because jmeter doesn't actively respond on the closed connection on tcp level, and keeping the TCP socket in a half open state on both ends (server and client/jmeter). This causes obvious errors as stated in this issue. So this ticket is about 2 issues: 1. JMeter (httpclient) isn't properly handling the FIN/ACK immediately, causing temporary half-closed sockets (CLOSE_WAIT and FIN_WAIT_2) 2. _Non HTTP response message: : failed to respond_ errors, in the situation if jmeter tries to do the next request on this socket, after the (web)server send its FIN/ACK (disconnect) packet, but before the httpclient4.validate_after_inactivity time -- 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
