Dans ce cas, je ne suis pas un parti, je viens de l'entendre, il peut donc y avoir de nombreuses expressions ambiguës.
Je me connectais au serveur depuis un client (Java) via LB, et la réponse du serveur a pris n minutes. Cela prend n minutes en raison de la grande quantité de données dans la demande, qui est une spécification dans un sens (sans le tsukkomi que ce n'est pas cool). Je savais que cela prendrait beaucoup de temps, mais après n minutes, la même requête est arrivée au serveur.
J'ai eu une erreur côté serveur car la même demande a été renvoyée, mais je ne savais pas qui a fait la figure ci-dessus (2). Il semble qu'il n'y ait pas eu d'exceptions particulières du côté client.
Le coupable était le client Java. Le LB que j'utilisais était censé renvoyer la nageoire côté client s'il n'y avait pas de réponse pendant n minutes. En Java, il était censé renvoyer sans autorisation. Comme indiqué dans la RFC2616, Java dit également que si vous ne pouvez pas vous connecter par POST, vous devez le renvoyer. Je pense que cela suit. De plus, cette fois, j'ai utilisé Commons-HttpClient (3.x), mais il semble que j'utilise la classe HTTPClient de Java en interne.
Il a été écrit en ici.
sun.net.http.retryPost (par défaut: true) Détermine si les demandes HTTP POST infructueuses sont automatiquement renvoyées au serveur. Dans ce cas, «échec» signifie que le serveur n'a pas envoyé une requête HTTP valide ou une IOException qui s'est produite.
Si la propriété ci-dessus est définie sur false, elle ne sera pas renvoyée. Cependant, à la fin, s'il n'y a pas de réponse pendant n minutes, une erreur se produira, donc ce n'est pas une solution fondamentale.
Recommended Posts