2009-06-12 2 views
8

J'ai un service WCF qui doit parfois retourner une erreur. Pour une raison quelconque, les appels à mon service commencent à expirer avec l'erreur suivante: "Le délai de la chaîne de requête a expiré en attente d'une réponse après 00: 00: 59.8906201. Augmentez la valeur du délai d'attente passée à l'appel pour demander ou augmenter le SendTimeout valeur sur la liaison.Le temps alloué à cette opération peut avoir été une partie d'un délai plus long. " Après l'examen du problème, un motif a émergé: Lorsque le service a renvoyé 10 fois une erreur, le délai d'attente commence. Donc, j'ai créé un TestService mis en œuvre par:Pourquoi mon service WCF renvoie une exception FaultException, expire après 10 appels?

public string GetData(int value) 
{ 
    throw new FaultException("A testerror occured"); 
} 

Et TestClient:

protected void RunTestGetData() 
    { 
     using (TestServiceReference.Service1Client client 
      = new WSPerformanceTester.TestServiceReference.Service1Client()) 
     { 
      try 
      { 
       client.GetData(1); 
       client.Close(); 
       outputWriter.WriteLine(string.Format("Call run in thread {0}: GetData()", Thread.CurrentThread.ManagedThreadId)); 
       outputWriter.Flush(); 
      } 
      catch (Exception e) 
      { 
       client.Abort(); 
       client.Close(); 
       outputWriter.WriteLine(string.Format("Error occured in thread {0}: GetData(): {1}", Thread.CurrentThread.ManagedThreadId, e.Message)); 
       outputWriter.Flush(); 
      } 
     } 
    } 

Cela se produit uniquement lorsque le service renvoie une FaultException. Si je lance une exception normale, le service peut continuer à fonctionner après le 10ème appel. Évidemment, je voudrais bien emballer mes exceptions, donc lancer des exceptions normales n'est pas une véritable option.

Pourquoi est-ce que je rencontre ces exceptions de dépassement de délai? Merci d'avance pour toute aide ..

Répondre

1

Apparemment, le code client devrait être comme suit:

protected void RunTestGetData() 
{ 
    TestServiceReference.Service1Client client 
     = new WSPerformanceTester.TestServiceReference.Service1Client() 
    try 
    { 
     client.GetData(1); 
    } 
    catch (FaultException e) 
    { 
     //Handle fault 
    } 
    try 
    { 
     if (client.State != System.ServiceModel.CommunicationState.Faulted) 
     { 
      client.Close(); 
     } 
    } 
    catch(Exception e) 
    { 
     outputWriter.WriteLine("Error occured in Client.Close()"); 
     outputWriter.Flush(); 
     client.Abort(); 
    } 
} 

Appel client.Abort() devrait toujours être un dernier recours.

+2

[la citation nécessaire] – piers7

1

Je peux me tromper ici, mais je pense que cela a quelque chose à voir avec l'hébergement du service WCF. Parce qu'il ne peut pas être en mesure de répondre à la demande en temps opportun. IIS sur Windows XP, par exemple, peut répondre à 5 demandes simultanées (dont je ne suis pas si sûr pour l'instant). Si plus de demandes sont faites, il va à une file d'attente.

Et je crois que cela pourrait perdre les demandes, et ne pas les traiter, car votre test ne fait rien d'autre qu'une exception.

2

Je pense que cela peut être dû au fait que le comportement par défaut d'un service WCF est de 10 sessions simultanées. Gardez-vous les connexions ouvertes après que les exceptions FaultExceptions se produisent? Vous pouvez essayer de modifier cette valeur dans la BehaviorConfiguration (ServiceThrottling> MaxConcurrentSessions) et voir si cela change quelque chose. Je vous suggère d'utiliser l'éditeur de configuration de Microsof Service pour vérifier quelles autres valeurs sont définies par défaut. (MSDN)

espérons que cette aide ...

+0

Mais le client.Abort() ou client.Fermer() ne devrait-il pas fermer la session? Et pourquoi cela se produit-il uniquement lors de l'utilisation de FaultException? –

+0

J'ai la même question que Jesper. N'importe qui? –

+1

Voir la réponse de @ Jarrod268 pour une explication ... merci! – RoelF

0

Essayez mon WCF modèle de service client API et voir si les mêmes résultats se produisent. Je suis pense que quelque chose ne va pas dans le code client ...

The Code

The PPT

Aussi, activer la journalisation WCF bavard sur le client et le serveur ...

3

Je ne t avoir suffisamment de points pour commenter, donc une nouvelle réponse ...

Les services auto-hébergés ne permettent qu'un maximum de 10 connexions simultanées - peu importe le transport. Si vous utilisez des services WCF à l'intérieur d'IIS/WAS, vous ne devriez pas avoir à vous en soucier (à moins que vous ne soyez sur XP/Vista où les connexions simultanées maximales sont également de 10).

Les différences entre une exception d'erreur et une exception régulière dans ce scénario peuvent expliquer le résultat que vous voyez. Rappelez-vous, une exception non gérée régulière bloque le canal. Ce faisant, je suppose que cela ouvre une connexion disponible. Quand vous retournez un défaut, il gagne automatiquement le canal car il vous permet de faire quelque chose avec la connexion et de gérer le défaut de votre côté car il s'agit d'une faute "attendue" alors qu'une exception non gérée ne le serait pas.

Même lorsque vous renvoyez une erreur, vous devez toujours annuler la connexion. En outre, il existe des ressources non gérées, veillez donc à implémenter IDisposable sur les appelants de vos clients/proxy.

2

Je faisais face au même problème. Un examen plus approfondi a révélé que je n'étais pas en train de fermer le client webservice après que j'aie fini de faire les appels au webservice. Une fois que j'ai fait cela, il n'a pas échoué, même après 10 appels de méthode au webservice. Voir l'exemple ci-dessous.

WebServiceClient svcClient = new WebServiceClient(); 

string returnValue = svcClient.GetDocumentName(fileId); 

svcClient.Close(); 

modèle approprié:

using(WebServiceClient svcClient = new WebServiceClient()) 
{ 
    return svcClient.GetDocumentName(fileId); 
} 

ClientBase implémente IDisposable, qui appelle Close() dans la méthode Dispose.

+3

Vous ne devriez pas envelopper vos clients de WCF avec using l'instruction. Voir l'article suivant: http://msdn.microsoft.com/en-us/library/aa355056.aspx –

+0

remerciements avait ce problème aussi bien, était assez difficile de tracer le problème. de toute façon merci de poster – zulucoda

Questions connexes