WSO2 ESB inconnu code d'erreur 102511

Question

J'ai récemment mis à jour WSO2 ESB à la version 4.7 sur le Windows Server 2008 R2 et rencontré l'erreur suivante tout simplement mandatement requête SOAP à un point final:

réponse de réception alors que le gestionnaire est dans un état incohérent REQUEST_HEAD

ERROR_CODE : 102511 
ERROR_MESSAGE : Error in Sender 
ERROR_DETAIL : Error in Sender 
ERROR_EXCEPTION : null 

Il est, que ce code d'erreur n'est pas décrit dans la documentation et sans exception, il n'est pas évident de savoir quoi en faire. Le code le plus proche que j'ai pu trouver était SND_INVALID_STATE = 102510 et à en juger par le code source, il semble que la requête soit accompagnée d'en-têtes non valides. Mais toutes les demandes ne sont pas échouées. La même requête peut passer ou échouer de manière aléatoire. J'ai enregistré toutes les demandes avec un violoniste et je les ai rejouées. Celui qui a échoué peut finalement passer et vice versa. Avant cela, j'ai déployé et testé une nouvelle version d'ESB sur mon ordinateur local (Windows 7) et j'ai rencontré cette erreur uniquement lors du démarrage à froid.

La configuration la plus simple pour le reproduire consiste en un service Path Through Proxy et un point d'extrémité d'adresse.

config service Proxy:

<?xml version="1.0" encoding="UTF-8"?> 
<proxy xmlns="http://ws.apache.org/ns/synapse" name="TestEP" transports="http" statistics="disable" trace="enable" startOnLoad="true"> 
    <target endpoint="TestEP"> 
     <outSequence> 
     <send/> 
     </outSequence> 
    </target> 
    <description/> 
</proxy> 

Adresse Endpoint Description

<endpoint xmlns="http://ws.apache.org/ns/synapse" name="TestEP"> 
    <address uri="http://mydomain.test/SystemServices.asmx"> 
    <syn:suspendOnFailure> 
     <syn:initialDuration>0</syn:initialDuration> 
     <syn:progressionFactor>1.0</syn:progressionFactor> 
     <syn:maximumDuration>0</syn:maximumDuration> 
    </syn:suspendOnFailure> 
    </address> 
</endpoint> 

Quelqu'un d'autre connu cette erreur ou sait comment faire face? Je serai reconnaissant pour tout aperçu de la situation.

Une mise à jour:
Il semble que la raison pour laquelle les demandes ne parviennent pas est

Expect: 100-continue 

l'option

dans l'en-tête HTTP demande. Lorsque j'ai créé une règle pour la supprimer dans fiddler, toutes les requêtes se sont déroulées avec succès. Il n'est pas encore clair s'il existe un moyen de traiter un tel comportement du côté WSO2 ESB ou si cette partie de l'en-tête doit être supprimée.

Answer 1

J'ai rencontré ce problème aujourd'hui lors de la mise à niveau de WSO2 ESB 4.5.1 à 4.7.0. J'ai eu un autre problème avec 4.5.1 que j'ai dû mettre à niveau à cause de, donc en rencontrant ce problème avec 4.7.0, je n'avais pas d'autre choix que de le résoudre. Après avoir réfléchi pendant un certain temps, je me suis souvenu que le transport par défaut était passé de NHTTP à Passthrough dans 4.6.0 pour augmenter les performances. 4.7.0 est livré avec des configurations pour les deux, mais avec PT activé par défaut.Les fichiers de configuration sont dans le répertoire axis2:

${carbon.home}/repository/conf/axis2/ 

Le fichier de configuration PT est axis2_pt.xml. Le NHTTP est le axis2_nhttp.xml. Vous pouvez les différencier pour avoir une idée de ce qui change; le diff est heureusement assez propre.

Vous pouvez facilement passer de PT à nhttp en modifiant le fichier de configuration principal:

${carbon.home}/repository/conf/carbon.xml 

Là, vous avez l'élément <ConfigurationFile> sous <Axis2Config>. Le fichier par défaut, axis2.xml semble être plus ou moins une copie de axis2_pt.xml. Pour passer à NHTTP, changez simplement le <ConfigurationFile> en ${carbon.home}/repository/conf/axis2/axis2_nhttp.xml.

Passer à NHTTP a résolu mon problème de ESB 4.7.0 ne traitant pas 100 CONTINUE correctement. Plus précisément, j'essayais de télécharger un PDF en utilisant curl à travers l'ESB à un autre service. En utilisant PT, il a échoué; en utilisant NHTTP, cela a bien fonctionné. Ma conclusion évidente est que PT est simplement bogué dans ce scénario. D'après ce que j'ai lu au sujet de PT vs NHTTP, le seul effet secondaire «officiel» du passage de l'un à l'autre est que le TP devrait être plus rapide dans certains scénarios. Cependant, NHTTP existe depuis plus longtemps et est donc susceptible d'être un peu plus solide simplement en raison d'avoir traversé plus de tours de correction de bogues. Je ne le sais pas avec certitude car je ne suis pas impliqué dans le développement de WSO2 ESB, mais c'est une supposition éclairée. :)

Aussi j'aimerais commenter sur la réponse de Isuru Perera, mais je n'ai pas la réputation nécessaire ainsi j'ai peur de devoir mettre mes deux cents concernant https://wso2.org/jira/browse/APIMANAGER-1007 ici. Ce problème semble en effet lié - en particulier basé sur ma propre expérience avec curl aujourd'hui - mais malheureusement les gens aimables à WSO2 ont résolu le problème comme "Pas un bogue" après un certain nombre de commentaires qui ont finalement recommandé d'éviter l'utilisation de curl "Travaillez comme prévu", ce qui en fait un "problème curl". IMHO ayant un comportement cassé avec des requêtes conformes à HTTP-spec n'est pas un problème client et doit être résolu. Ceci rend effectivement le transport PT inutilisable dans certains scénarios - c'est-à-dire ceux dans lesquels le client est un peu plus intelligent sur la façon dont il POSTE de grands corps. C'est vraiment dommage, car les scénarios où le corps de la requête n'a pas besoin d'être analysé sont précisément ce pour quoi le transport PT a été conçu et où il devrait exceller! Oh et voici mon premier article sur stackoverflow donc je suis désolé si j'ai enfreint les règles de la maison; J'ai été un participant passif pendant un certain temps donc j'espère que je n'ai rien fait de mal!

Answer 2

Il semble qu'une erreur similaire s'est produite avec WSO2 API Manager également. Voir https://wso2.org/jira/browse/APIMANAGER-1007

ESB s'exécute dans le gestionnaire d'API et, par conséquent, vous pouvez rencontrer un problème similaire à celui mentionné dans le JIRA comment.

Doc suivant a répertorié la plupart des codes d'erreur.

http://docs.wso2.org/wiki/display/ESB470/Error+Handling

Mais le code d'erreur mentionné dans cette question ne figure pas malheureusement.