2010-12-06 50 views
1

Je reçois des exceptions d'expiration de délai Microsoft.Http.HttpStageProcessingException répétées lorsque j'essaie d'utiliser le HttpClient du kit de démarrage REST. Cela a fonctionné correctement lorsqu'il est utilisé localement, mais échoue lorsque vous allez à distance.WCF REST StarterKit HttpClient: Temporisation de HttpClient lors de la connexion à distance - fonctionne correctement localement ou via un proxy local

Le client est un processus C# qui s'exécute en tant que service Windows et utilise HttpClient pour effectuer des appels REST sur notre serveur d'applications Java exécuté dans Tomcat6. Lorsque j'ai commencé à résoudre ce problème, je suis tombé sur un message similaire sur les forums MSDN: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc

Malheureusement, je ne peux pas l'isoler simplement à un problème de longueur de contenu.

Si quelqu'un a des suggestions sur la façon de résoudre ce problème, j'apprécierais grandement - même si cela signifie utiliser HttpWebRequest directement. Je comprends HttpClient utilise HttpWebRequest sous le capot, mais peut-être qu'il fait des suppositions.

+0

Y at-il un proxy entre vous et le serveur WCF? – Aliostad

+0

Pouvez-vous afficher le code que vous utilisez pour lire la réponse? Mon expérience a été que si vous ne consommez pas complètement le flux de réponse, la demande peut être bloquée. –

+0

après un peu plus d'expérimentation, j'ai vérifié que cela se produit uniquement avec les appels REST qui ont du contenu associé. – Bob

Répondre

0

Si cela fonctionne localement ou à distance via Fiddler, il y a un problème avec le proxy HTTP. Votre configuration actuelle n'utilise pas de proxy mais Fiddler utilise par défaut un proxy configuré pour IE.

+0

il ya une différence majeure, entre ma logique en utilisant HttpClient et Fiddler - Fiddler utilise des Sockets raw, pas de WebRequest [comme HttpClient fait sous le capot]. – Bob

+0

Mais il utilise encore le protocole HTTP. –

1

Trouvé la solution. Il s'avère que le nombre par défaut de connexions HTTP sortantes lors de l'utilisation de HttpClient semble être 2. Après avoir utilisé le singleton statique ServicePointManager pour définir le DefaultConnectionLimit pour mon client AppDomain à 10, tout a bien fonctionné. Maintenant, c'est un peu inquiétant, parce que je suis habitué à écrire des applications multi-thread et à utiliser les nouvelles tâches .NET 4 - donc je n'aime vraiment pas avoir des limites strictes sur les connexions sortantes. Quelqu'un peut-il fournir des liens qui fournissent des détails sur la façon dont la gestion Http .NET de bas niveau fonctionne et quels boutons contrôlent quels paramètres?

Merci encore pour l'aide, Bob

NEVERMIND - trouvé moi-même, aurait dû googlé d'abord - ce blog MSDN sur le protocole client Http fournit une bonne description de ce qui se passe sous le capot: httpclient protocol blog

0

Obtenez le même problème et la solution est à la méthode Dispose sur la réponse (méthode peut-être nommé Close peut être plus clair) réponse reste toujours présent sur le socket et vous devez augmenter la DefaultConnectionLimit pour ouvrir nouveau socket pour chaque nouveau jusqu'à ce demande portée limite maximale (sale et lente).

Donc, la solution est:

HttpResponseMessage resp = this.HttpClient.Delete(uri);//or verb get/post/put 
try { 
    //.... do what you need with response 
} 
finally { 
    resp.Dispose(); //free the socket for a new request 
}