WCF arrête de répondre après environ 10 appels (étranglement)
J'ai un service WCF et une application avec une référence de service à celui-ci, et avec l'application, j'ai une boucle et dans chaque itération, il effectue un appel à une méthode de ce service Web WCF.
Le problème est qu'après environ 9 appels environ, cela arrête simplement ... et si vous appuyez sur Pause bouton de VS, vous verrez qu'il est bloqué sur la ligne où elle fait l'appel.
Après un certain temps en attendant, cela TimeoutException est lancé:
Le canal de demande a expiré en attendant une réponse après 00: 00: 59.9970000. Augmentez la valeur du délai d'attente passée à l'appel à demander ou à augmenter la valeur SendTimeOUT sur la liaison. Le temps imparti à cette opération peut avoir été une partie d'un délai plus long.
J'ai étudié un peu à ce sujet et j'ai trouvé des solutions impliquées de modifier l'app.config dans l'application, et voici des extraits de celui-ci:
<serviceBehaviors>
<behavior name="ThrottlingIssue">
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
</behavior>
</serviceBehaviors>
.
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
Ensuite, après que je cesse de déboguer, après quelques minutes, un message d'erreur apparaît me disant que A échec catastrophique s'est produite.
Comment puis-je résoudre ce problème? Je n'avais pas cette question lorsque je travaillais avec un service Web normal.
Pour référence, voici l'ensemble app.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ThrottlingIssue">
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IDBInteractionGateway" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:28918/DBInteractionGateway.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IDBInteractionGateway"
contract="DBInteraction.IDBInteractionGateway" name="WSHttpBinding_IDBInteractionGateway">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
</configuration>
[Mettre à jour] Solution :
Apparemment, après chaque demande que vous devez avoir à Close la connexion ... Je ferme maintenant la connexion après chaque demande et cela fonctionne comme un charme.
Bien que ce que je ne puisse toujours pas comprendre, c'est que dans mon app.config, j'ai mis mes maxconcurrentcalls et ma MaxConCurrentSessions à 500, et pourtant, je ne peux pas faire que 10. Quelqu'un a une réponse à une réponse pour celui-ci ? (Peut-être que j'ai quelque chose qui ne va pas dans mon app.config affiché ci-dessus)
La réponse de la question ci-dessus (maintenant en pointillée) est parce que je modifiez le client app.config, pas le fichier de configuration de service (web.config)
Le nombre par défaut de connexions simultanées autorisées est de 10.
[.____] Le plus probable que votre client ne ferme pas les connexions.
Pour augmenter le nombre d'appels simultanés, vous devrez ajouter votre comportement à la configuration du service, et non au client.
Un appel à Clientervice.close () résoudra le problème.
Cela peut être résolu en créant une classe Singleton en tant qu'interface entre référence Web Service et application. Ensuite, il ne créera qu'une seule instance de référence de service.
class ServiceInterface
{
private static ServiceInterface _instance;
private ServiceClient _service = new ServiceClient ;
private ServiceInterface()
{
//Prevent accessing default constructor
}
public static ServiceInterface GetInstance()
{
if(_instance == null)
{
_instance = new ServiceInterface();
}
return _instance;
}
// You can add your functions to access web service here
Public int PerformTask()
{
return _service.PerformTask();
}
}
Pouvez-vous configurer le traçage et exécuter la boucle? Il se peut que le canal est en train de devenir faute et que le client tient à tendre le temps.
Après avoir tiré mes cheveux sur un beaucoup problème similaire non résolu par Close() ou Dispose() je voudrais Ajoutez une solution simple qui a fait ma journée, notamment en augmentant le ServicePointManager.DefaultConnectionLimit qui est par défaut 2.
"La propriété defaultConnectionLimit définit le nombre maximum de connexions simultanées par défaut que l'objet ServicePointManager attribue à la propriété ConnectionLimit lors de la création d'objets de service."
Dans mon cas, mon application connectée avec succès à mon service à distance 2 fois, à la troisième tentative, il n'a tout simplement pas essayé de se connecter au service. Au lieu de cela, il attendit un moment avant de terminer le même message d'erreur que dans la question ci-dessus. Augmenter DefaultConnectionLimit résolu ceci. Pour ajouter à la frustration, ce comportement était quelque peu aléatoire - dans un cas de 10 Web Webservice a été invoqué avec succès multiple (> 2) fois.
La solution provient et sont en outre discutées sur ces deux threads: Timeout WCF-Timeout-Exception-Exception-Investigation et WCF-Service-Logement . résolu mon problème.