:ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool:
Nous avons passé, avec les collègues, quelque heures à comprendre ce qui se passait sur bug qui se traduisait par des temps de réponses et des ko pour non réponse, lors d'appel de webServices en production.
Le problème est identifié et comme ma recherche sur développez.net n'a pas donné de résultat je me suis dis que ce ne serait pas mal de le documenter pour les autres.
OBJET
Dans un cadre d’appel http, si l’on utilise le Framework CXF, quelques précautions sont à prendre dans la configuration du client afin d’éviter un comportement du client pouvant générer des incidents de production.
Ceci notamment si l’on doit authentifier les appels.
CONSTAT
Lors d’appels HTTP vers des WebServices, on constate que certains appels n’aboutissent pas et tombent en « TimeOut » client pour non réponse du WebService distant.
Le WebService distant semble anormalement long ou en « stalled ».
Les fichiers de log client indiquent une SocketTimeoutException en Read timed out
La survenance du bug est aléatoire.
ANALYSE
- Traces applicatives et log
En prenant une trace applicative sur le client on constate que la requête est correctement construite sur CXF mais qu’ensuite la succession des paquets envoyés est incomplète avant le déclanchement du SocketTimeoutException.
Les fichiers de logs client n’apportent pas plus d’informations que les piles d’exceptions du timeout.
Les fichiers de logs Serveur montrent bien l’arrivée de la requête mais sans complétion, puis notent une fermeture de session tcp client.
:alerte::alerte::alerte: On peut déterminer qu’il s’agit bien d’un TimeOut prononcé par le client pour non réponse du serveur alors que le serveur attend la complétion de la requête.
CLIENT :
La trace du réseau coté client permet de constater que le timeout prononcé correspond à chaque fois à une même caractéristique et forme de bug.
La session TCP est correctement et rapidement ouverte, les acquittements sont corrects.
Le dysfonctionnement est caractérisé par l’émission d’une commande HTTP POST sans poursuite par l’émission du BODY HTTP accompagnant le POST.
A l’issue de la durée de Timeout (60s) on constate une fin de session TCP émise (FIN ACK)
SERVEUR :
On constate bien l’arrivée du POST à T0 après ouverture rapide de session TCP.
Le serveur se met en attente de réception du BODY.
A l’issue de la durée de Timeout (60s) on constate une fin de session TCP demandée par le client (FIN ACK) et on acquitte la demande de fin de session.
:bug: En fait la documentation du client pour le Framework CXF indique une incompatibilité entre les options : :nono:
• Transfer encoding = chunked
Et
• Basic Authentication
Comme l’option de Transfer encoding est positionnée par défaut il est nécessaire de la configurer à « false ».
:yaisse1:
CORRECTION
Pour utiliser le Framework CXF dans un contexte d’appel authentifié, il faut configurer explicitement certaines options du bus et du conduit http.
Dans ce cas de figure, il faut impérativement configurer dans le conduit, l’option du client AllowChunking= “false“ de façon explicite.
Cela résout complètement le bug de communication du POST sans le BODY, donc un appel de WebService sans l’enveloppe soap produisant un ko.
Exemple de configuration :
•
http://cxf.apache.org/docs/client-ht...l-support.html
• Chapitre « The client element », attribut « AllowChunking »
Dans une config CXF client chargée par l’appli :
…
<!-- parametrage du conduit HTTP -->
<http:conduit name="*.http-conduit">
<http:client ReceiveTimeout="${webservice.client.timeout.receive}" ConnectionTimeout="${webservice.client.timeout.connexion}" AllowChunking="false" />
</http:conduit>
…
:lahola::lahola::lahola:
:ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool::ccool:
