web-dev-qa-db-fra.com

Valeurs par défaut du délai d'expiration HttpURLConnection

Il semble que j'ai des problèmes avec certaines requêtes TCP qui se "bloquent" parfois, comme si elle attendait une réponse, mais la connexion a été "rompue", donc aucune réponse ne viendra. Ce comportement est-il attendu pour HttpURLConnection avec des délais d'expiration par défaut? Y a-t-il des valeurs par défaut raisonnables pour que je ne puisse pas entrer dans cette étrange situation "bloquée" par défaut?

10
rogerdpack

Apparaît que les délais d'attente "par défaut" pour HttpURLConnection sont zéro, ce qui signifie "pas de délai d'attente".

Malheureusement, d'après mon expérience, il semble que l'utilisation de ces valeurs par défaut puisse conduire à un état instable, selon ce qui se passe avec votre connexion au serveur. Si vous utilisez un HttpURLConnection et ne définissez pas explicitement (au moins en lecture) des délais d'attente, votre connexion peut entrer dans un état périmé permanent. Par défaut. Par conséquent, définissez toujours setReadTimeout sur "quelque chose", sinon vous pourriez utiliser des connexions orphelines (et éventuellement des threads en fonction du fonctionnement de votre application).

Il ressort des essais et erreurs que l'appel de setConnectTimeout n'est pas requis car le socket lui-même semble avoir un "délai de connexion" de 2 minutes intégré (au moins sous OS X).

Vous pouvez également définir une "valeur par défaut globale" pour les délais d'expiration en ajustant propriétés système .

Correction/pronostic: définissez toujours un readTimeout (même s'il est très volumineux), ou utilisez un client différent qui vous permet de définir SO_KEEPALIVE . Par défaut, votre programme peut se bloquer "pour toujours" sans lui.

22
rogerdpack