jgaalen commented on issue #6330: URL: https://github.com/apache/jmeter/issues/6330#issuecomment-2621168118
> > because this means the server is trying to shut down the socket, but the client didn't do it yet > > First, if the server was about to close the connection it should probably send `Connection: close` header, so the client knows the server does not want reusing the connection. No, with keep-alive (http/1.1 standards), it can disconnect whenever it wants. In many cases it can be after just 2 seconds. The connection: close is only a hint from the client to request the server to close the connection immediately after the response. If the server does a connection: keep-alive it certainly doesn't mean it would keep the connection open for unlimited time, and it will disconnect at some point (could vary between near instant, to 1, 2, or whatever seconds). When the server is disconnecting earlier than the httpclient4.validate_after_inactivity setting, that JMeter is getting into the problem-zone, because if the thread tries to do a request AFTER the server sent the disconnect, but before the validate_after_inactivity value (default 4900ms), then you'll get got non-http error. > > Second, I'm afraid the only way to tell if "server" closes a connection is to read/write something to the connection. That means if the server silently closes a connection (which is (un)fortunately allowed by various HTTP RFCs) the client does not get an immediate notification, thus it can't discard the connections right away. Sending a FIN/ACK is. I think, not a silently closed connection, but a clear message to the client that is is actively closing the connection. In fact, it gets the packet/message so there is nothing silent about it. > > Frankly, it is not clear what clients are supposed to do with all this. It is not clear how Java implementation handles "silent connection close" It is clear, it should reconnect if it want to do a new/next request. The problem is in httpclient4, where it is not actively closing the socket/responding to the FIN/ACK. It knows it is there, because if you want to do a request AFTER the httpclient4.validate_after_inactivity time, it does know the socket was requested to be closed and acts how it supposed to, but should have done it immediately when it got the FIN/ACK. > > > I think this is a bad implementation in the HttpClient4 library. It should simply remove a connection once the server requests it. > > Looks so, however, as the only way to detect "server-side closure" is to write data, so HttpClient4 should detect "IOException when writing headers", and retry the request. It looks like https://www.rfc-editor.org/rfc/rfc2616.html#section-8.2.4 specifies that, however, I'm not sure if that is the currently active RFC. This is the whole idea of this ticket, it doesn't do so and jmeter throws this non-http error (because httpclient sends data on the socket in half-state and receives a RST from the server). https://datatracker.ietf.org/doc/html/rfc9293#name-closing-a-connection In the end, we can look into standards, if it is throwing errors where it is not supposed to do, and if it is not acting as browsers/client do, there is a bug -- 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
