In this case, I am not a party, I just heard it, so there may be many ambiguous expressions.
There was an event that the client (Java) was connecting to the server via LB and the response from the server took n minutes. It takes n minutes because of the large amount of data in the request, which is a specification in a sense (without the tsukkomi that it is not cool). I knew it would take a long time, but after n minutes, the same request arrived at the server.
Since the same request was resent, an error occurred on the server side, but I did not know who made the above figure (2). It seems that there were no particular exceptions on the client side.
The culprit was the client Java. The LB I was using was supposed to return fin to the client side if there was no response for n minutes. In Java, it was supposed to resend without permission. As stated in RFC2616, Java also says that if you cannot connect by POST, you should send it again. I think it follows that. In addition, this time I used Commons-HttpClient (3.x), but it seems that I am using Java's HTTPClient class internally.
It was written in here.
sun.net.http.retryPost (default: true) Determines whether unsuccessful HTTP POST requests are automatically resent to the server. In this case, "unsuccessful" means that the server did not send a valid HTTP request or an IOException that occurred.
If the above property is set to false, it will not be resent. However, in the end, if there is no response for n minutes, an error will occur, so it is not a fundamental solution.
Recommended Posts