In diesem Fall bin ich keine Partei, ich habe es gerade gehört, daher kann es viele mehrdeutige Ausdrücke geben.
Ich habe von einem Client (Java) über LB eine Verbindung zum Server hergestellt, und die Antwort vom Server dauerte n Minuten. Es dauert n Minuten wegen der großen Datenmenge in der Anfrage, die in gewissem Sinne eine Spezifikation ist (ohne das Tsukkomi, dass es nicht cool ist). Ich wusste, dass es lange dauern würde, aber nach n Minuten traf dieselbe Anfrage auf dem Server ein.
Auf der Serverseite ist ein Fehler aufgetreten, da dieselbe Anforderung erneut gesendet wurde, aber ich wusste nicht, wer die obige Abbildung (2) erstellt hat. Es scheint, dass es auf der Client-Seite keine besonderen Ausnahmen gab.
Schuld daran war der Client Java. Die LB, die ich benutzte, sollte fin an die Client-Seite zurückgeben, wenn n Minuten lang keine Antwort erfolgte. In Java sollte es ohne Erlaubnis erneut gesendet werden. Wie in RFC2616 beschrieben, sagt Java auch, dass Sie es erneut senden sollten, wenn Sie keine Verbindung per POST herstellen können. Ich denke, daraus folgt. Außerdem habe ich diesmal Commons-HttpClient (3.x) verwendet, aber es scheint, dass ich die HTTPClient-Klasse von Java intern verwende.
Es wurde in [hier] geschrieben (https://docs.oracle.com/javase/jp/8/docs/technotes/guides/net/properties.html).
sun.net.http.retryPost (Standard: true) Legt fest, ob nicht erfolgreiche HTTP-POST-Anforderungen automatisch an den Server erneut gesendet werden. In diesem Fall bedeutet "nicht erfolgreich", dass der Server keine gültige HTTP-Anforderung oder eine aufgetretene IOException gesendet hat.
Wenn die obige Eigenschaft auf false gesetzt ist, wird sie nicht erneut gesendet. Wenn jedoch am Ende n Minuten lang keine Antwort erfolgt, tritt ein Fehler auf, sodass dies keine grundlegende Lösung darstellt.
Recommended Posts