Nous avons un service WCF (BasichttpLinding) qui échouera toujours après 30 secondes. Appels moins de 30 secondes complète sans erreur. Plus de 30 secondes échouera avec une exception de 502 Bad Badway:
system.net.webException: le serveur distant a renvoyé une erreur: (502) Bad Gateway. P> BlockQuote>
Mais pourtant, l'appel de la WCF continue de fonctionner en arrière-plan (et finira par terminer). Nous avons confirmé que la liaison BasichttpLinding - SendTimeOUT (en web.config) est supérieure à 30 secondes (réellement réglée sur 5 minutes). Nous avons confirmé cela à la fois sur le client et le serveur. P>
Voici la trace de la pile complète: p>
xxx pré> Toutes idées où ce «délai d'attente» de 30 secondes est En venant de ou pourquoi une erreur de passerelle Bad 502 est renvoyée? P>
solution: Nous utilisons le module de routage de demande d'application IIS7 qui contient des paramètres de proxy. Les paramètres de proxy ont un délai d'attente par défaut de 30 secondes. Augmenter cela à 600 secondes (10 minutes) a résolu notre problème. L'erreur de passerelle Bad n'est pas complètement correcte mais la visualiseur de trace de la WCF (voir réponse) aidé à voir que le problème n'était pas le service lui-même mais un problème entre le client et le service WCF. P> p>
3 Réponses :
Vous voudrez peut-être essayer d'essayer de modifier les autres valeurs de configuration du délai d'attente: p>
CLOSEMETIMEOUT, OPENTIMEOUT, recouvreTimeOut. P>
Voir MSDN POST Pour plus d'informations sur les éléments de configuration, Résumé ci-dessous: P>
côté client: p>
- SendTimeout est utilisé pour initialiser l'opération platie, qui régit toute l'interaction pour l'envoi d'un message (y compris recevoir un message de réponse dans un cas de réponse de demande). Ce délai d'attente aussi S'applique lors de l'envoi de messages de réponse d'une méthode CallbackContract. Li>
- opentimeout et closeumeout sont utilisés lors de l'ouverture et de la fermeture des canaux (lorsqu'il n'y a pas de valeur de délai d'attente explicite). LI> ul>
côté serveur: p>
- Envoyer, ouvrir et fermer le timeout identique que sur le client (pour rappel). Li>
- ReceiveTimeOut est utilisé par ServiceFramework Couche pour initialiser le délai de session-inactif. Li> ul> blockQuote>
ajouté: p>
La seule autre chose que je peux suggérer est d'utiliser le visualiseur de trace de service WCF pour aller au bas de ce qui cause le problème. Voir cette Donc, POST Si vous avez besoin de détails sur la façon de l'utiliser. p>
Nous avons essayé d'augmenter la clientèle, opentimeout et recevoir à 5 minutes (sur le client et le serveur) et voir toujours le problème.
Merci pour les informations sur la visionneuse de trace de service WCF. Je l'ai utilisé pour recueillir une trace sur le client et sur le serveur, mais tout ce que je constate de ce que le serveur se termine correctement, mais le client finit par une "réponse HTTP incorrecte reçue" avec le message interne étant "Le serveur distant renvoyé une réponse inattendue: (502) Bad Gateway. " Le serveur est terminé après 42 secondes et le client obtient l'erreur à 31 secondes. Il est toujours 31 secondes pour le client.
Deviner. Nous utilisons le module de routage de demande d'application IIS7 qui a des paramètres de proxy dont l'un était un délai de 30 secondes. L'utilisation de WCF Service Trace Viewer m'a aidé à comprendre que le service WCF n'était pas le problème, mais quelque chose entre le client et le service.
J'ai frappé ce problème même moi-même aujourd'hui. Le téléchargement d'un fichier sur un service Web WCF à partir d'une application SL4 a continué d'augmenter une exception ConnectionTimeout après 30 secondes.
J'ai trouvé la cause du problème d'être l'utilisation de la méthode WebRequest.registerprefix comme recommandé par Microsoft pour surmonter la manipulation d'exception de défilement à Silverlight : p> voir http://msdn.microsoft.com/en-us/library/ee844556 (v = vs.95) .aspx p> p>
IIS -> Paramètres avancés -> Limites de connexion P>
Augmentez ce nombre (en secondes) au montant souhaité. P>
J'espère que cela aide tous les googleurs là-bas! P>