Où devrais-je commencer à enquêter sur SocketTimeoutException: Read timed out
De temps en temps, je vois StackTrace suivant dans le journal dans lequel, HttpClient socket expire en essayant d'accéder au contenu text/script à partir d'un autre serveur. Ma question Est de savoir quels paramètres de configuration dois-je vérifier pour mon application J2EE fonctionnant sur Weblogic, sous Linux? Je suis spécifiquement à la recherche de ce qui suit.
- paramètres de délai D'attente JVM
-
HttpClientparams - Weblogic timeout params ou toute autre configuration comme le nombre de threads, etc.
- paramètres de l'Application J2EE comme servlet config etc.
- ressources du système D'exploitation comme les threads, les gestionnaires de fichiers et le processeur
- tous les autres paramètres de configuration qui pourraient influencer la connexion du socket
- les vidages de threads aideraient-ils?
Voici mon code
HTTPResponse httpClientResponse;
//do some stuff
httpClientResponse.getStatusCode(); // this is where it fails
Et ceci est le stacktrace
java.net.SocketTimeoutException: Read timed out
at jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
at jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at HTTPClient.BufferedInputStream.fillBuff(BufferedInputStream.java:206)
at HTTPClient.BufferedInputStream.read(BufferedInputStream.java:126)
at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:356)
at HTTPClient.RespInputStream.read(RespInputStream.java:147)
at HTTPClient.RespInputStream.read(RespInputStream.java:108)
at HTTPClient.Response.readResponseHeaders(Response.java:1123)
at HTTPClient.Response.getHeaders(Response.java:846)
at HTTPClient.Response.getStatusCode(Response.java:331)
at HTTPClient.RetryModule.responsePhase1Handler(RetryModule.java:92)
at HTTPClient.HTTPResponse.handleResponseImpl(HTTPResponse.java:872)
at HTTPClient.HTTPResponse.access$000(HTTPResponse.java:62)
at HTTPClient.HTTPResponse$2.run(HTTPResponse.java:839)
at HTTPClient.HTTPResponse$2.run(HTTPResponse.java:837)
at
HTTPClient.HttpClientConfiguration.doAction(HttpClientConfiguration.java:666)
at HTTPClient.HTTPResponse.handleResponse(HTTPResponse.java:837)
at HTTPClient.HTTPResponse.getStatusCode(HTTPResponse.java:242)
Merci
Je vais mettre à jour ma question avec les résultats ci-dessous.
- Il N'y a pas de délai d'attente explicite défini sur {[2] } ce qui signifie que http le délai d'attente de session du serveur peut être la prise d'un effet.
-
SO_TIMEOUTpourHttpClientest 0, ce qui signifie qu'il devrait attendre indéfiniment.
3 réponses
Piste 1
Selon le javadocs Httpclient ne semble pas avoir une valeur par défaut du délai D'attente du Socket. Pour répondre à la question dans votre mise à jour-le délai d'attente de session ne sera pas en vigueur ici. La valeur par défaut de Weblogic est de 30 minutes pour le délai d'attente de la session.
Le serveur session timeout représente la quantité de temps que l' HttpSession sera conservé en mémoire si l'utilisateur a accédé au serveur.
Le délai d'attente du socket est la durée de conservation du socket du serveur ouvert pendant que les données sont transférées à l'appelant. Cela pourrait même être que le serveur est toujours en train de traiter et d'écrire des données, mais cela prend assez de temps et le client vient de l'attendre.
Certains liens suggèrent que cette valeur par défaut est de 60 secondes mais les javadocs ne disent rien, en tout cas vous pouvez définir cette valeur à quelque chose comme 120 secondes pour voir si elle aide
Ce dont vous avez besoin est de chronométrer les délais d'attente-si c'est clair. Signification - ces erreurs apparaissent-elles après 30 secondes, 60 secondes ou 5 minutes de la requête sortante?
Je voudrais changer le SO_Timeout et réessayer
Piste 2-paramètres du système d'exploitation
Il y a les paramètres Bea recommandés pour les valeurs NDD qui régissent comment les connexions entrantes longues sont maintenues ouvertes et combien sont mises en file d'attente et ainsi de suite. Sur Solaris, ceux-ci sont obtenus en exécutant
/usr/sbin/ndd -get /dev/tcp tcp_time_wait_interval
/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q
/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q0
/usr/sbin/ndd -get /dev/tcp tcp_ip_abort_interval
/usr/sbin/ndd -get /dev/tcp tcp_keepalive_interval
Pouvez-vous vérifier les documents Oracle pour les commandes équivalentes sur Linux, et à quelles valeurs elles doivent être définies? Sur Solaris, mon expérience est que les valeurs par défaut ne sont pas suffisantes et qu'elles doivent être augmentées aux recommandations BEA (Oracle)
Piste 3: Weblogic / Journaux D'Accès Externe
Avez-vous activé les journaux D'accès HTTP sur le serveur? Ces demandes ayant échoué apparaissent avec une taille d'octet de réponse ou montrent-ils une taille de réponse 0? Quel code d'erreur ou code D'état HTTP est retourné?
Ou peut-être que ces temporisés ne sont pas du tout enregistrés dans les journaux d'accès?
Ici, je suppose que le serveur externe sur lequel les temps morts se produisent est également Weblogic, sinon-cette question est dirigée vers l'équipe du serveur externe pour leur plate-forme équivalente.
** Autres **
Habituellement, les vidages de thread aident, mais les vidages de thread doivent être pris sur le serveur qui a un problème de délai d'attente. Vous êtes le client et vous avez obtenu avec succès une connexion, après cela, il expire lors de la lecture de la réponse. Alors, le serveur externe surchargé ? Manque de threads? CPU élevé? Trop de demandes simultanées?
Un autre aspect qui n'a pas été couvert ici est le pare-feu.
J'ai trouvé que SocketTimeoutExceptions peut souvent être liée à un port non ouvert pour la communication ou à un pare-feu bloquant la communication à partir de machines sélectionnées uniquement.
Dans le cas où vous déboguez un problème, assurez-vous également d'examiner s'il existe un pare-feu entre les deux machines essayant de communiquer et s'il y en a un, assurez-vous que les ports sont disponibles pour la communication entre le de deux.
Les choses intéressantes à propos des problèmes liés au pare-feu sont qu'il ne vous permet pas de savoir si le serveur est en panne ou ne répond pas. Le comportement typique est de laisser le client attendre pour toujours. Donc, vous êtes toujours laissé dans l'obscurité. Un telnet simple sur le port du serveur devrait montrer si son Disponible / ouvert pour la communication.
J'espère que cela aide.
Vous devriez enquêter
(a) le délai de lecture HttpClient par défaut ou explicite, selon celui qui est utilisé;
(B) pourquoi le serveur ne répond pas pendant cette période, s'il est supposé le faire (voir les journaux du serveur),
(C) sinon pourquoi le délai d'attente est trop court. De nombreux délais d'attente sont trop courts, par exemple quelques secondes. Ils devraient être une fraction décente d'une minute, et si le temps de réponse attendu est plus long, doubler ou tripler le temps de réponse attendu.