WCF cesse de répondre après environ 10 ou si les appels (limitation)

Question

J'ai un Service WCF et d'une application avec un Service de Référence, et avec l'application j'ai une boucle et à chaque itération, c'est de faire un appel à une méthode dans cette web wcf-service.

Le problème est que, après environ 9 appels ou alors, il s'arrête juste...et si vous frappez Pause bouton de VS, vous verrez qu'il est coincé sur la ligne où il fait l'appel.

Après un certain temps d'attente pour elle, ce TimeoutException est levée:

Le canal de demande dépassé lors de la en attente d'une réponse après 00:00:59.9970000. Augmenter le délai d'expiration la valeur transmise à l'appel à la Demande ou augmentation de la SendTimeout valeur sur le De liaison. Le temps alloué à cette l'opération peut avoir été une partie d'un délai plus long.

---

J'ai fait des recherches un peu sur ce, et a trouvé des solutions qui participent d'édition de l'application.config de 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" />

Puis, après que j'ai arrêter le débogage, après quelques minutes, un message d'erreur s'affiche me disant qu'une défaillance Catastrophique a eu lieu.

Comment puis-je résoudre ce problème? Je n'ai pas ce problème lorsque je travaillais avec un Service Web normal.

---

Pour référence, voici la toute l' 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>

---

[Mise À Jour] Solution:

Apparemment, après chaque demande que vous avez à l' Close le lien...je suis maintenant de fermer la connexion après chaque demande, et il fonctionne comme un charme.

Bien que ce que je ne comprend toujours pas, c'est que dans mon application.config, j'ai mis mes paramètre et maxConcurrentSessions à 500, et pourtant, je ne peux que faire 10. Quelqu'un a une réponse pour celui-ci? (j'ai peut-être quelque chose de mal dans mon application.config posté ci-dessus)

La réponse à la question ci-dessus (maintenant en pointillés) c'est parce que j'étais édition de la client app.config, pas le fichier de configuration du service (web.config)

Answer 1

La valeur par défaut nombre de connexions simultanées est de 10.
Il est probable que votre client ne ferme pas les connexions.

Pour augmenter le nombre d'appels simultanés, vous devrez ajouter votre comportement à la configuration de service, pas le client.

Answer 2

Un appel à clientservice.close() va résoudre le problème.

Answer 3

J'ai rencontré ce problème cette semaine et je n'étais pas en mesure de comprendre ce qui se passait. J'ai fait changer mon appel à mon service de Dispose() le service client, mais il ne semble pas avoir d'effet. Apparemment, il y avait un autre appel de service caché quelque part.

Ce qui peut être intéressant à noter, c'est ce qui m'a fait décider que ce n'était pas le problème: cette limite n'est pas liée au nombre actuel de connexions de socket à l'webservice. Quand vous frappez l' maxConcurrentSessions de la limite, il n'y a toujours qu' une seule connexion de socket. J'ai été vérifier cela avec netstat, ce qui m'a amené à une conclusion erronée. Donc, ne pas confondre les sessions avec des sockets.

Nous avons interfaces définies pour l'ensemble de nos services WCF, donc je suis la planification d'adapter ce modèle dans mon code maintenant:

IMyService service = new MyServiceClient();
using (service as IDisposable)
{
    service.MyServiceMethod();
}

Ce qui est intéressant aussi, c'est que le problème ne se produit pas pour moi quand les services (et site web) ont été hébergée sur IIS. La configuration est (presque) identique, mais je ne pouvais pas reproduire ce problème sur cette machine. Je suppose que c'est une bonne chose :)

@ John Saunders (à propos de l'attribution de la variable en using):

J'ai l'habitude de ne mettre l'affectation de variable dans l' using déclaration. Mais le IMyService généré n'est pas implicitement convertible IDisposable. Si tu voulais vraiment l'attribution de là, je suppose que l'alternative serait de:

IService service;
using ((service = new ServiceClient()) as IDisposable)
{
}

Qui laisse encore le problème de l'étendue de la variable d'être mal. La référence à l' IService service est inutilisable, mais toujours dans la portée. Donc ce serait mieux en la matière:

using (IDisposable serviceDisposable = new ServiceClient())
{
     IService service = (IService)serviceDisposable;
}

Qui m'oblige à introduire une variable supplémentaire nom si. *Meh*

Answer 4

Ce problème peut être résolu par la création de classe singleton comme interface entre le service web de référence et de l'application. Puis il va se créer qu'une seule instance du service de référence.

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();
    }
}

Answer 5

Pouvez-vous configurer le suivi et l'exécution de la boucle? Il se peut que le canal est en train de devenir défaillant et en forçant le client à temps.