Identifier les clients WCF qui ne disposent pas correctement

Nous avons un service WCF hébergé dans IIS. Maintenant, il existe de nombreuses applications clientes appelant ce service. WS-SecureConversion est utilisé. Maintenant, le journal de diagnostic du service affiche des avertissements indiquant que les sessions de sécurité sont annulées. Cela est probablement dû à des clients qui ne clôturent pas correctement la session.Identifier les clients WCF qui ne disposent pas correctement

Plus d'informations: le problème étaient des sessions de sécurité "en attente". Ce sont des sessions qui n'ont jamais été utilisées, seulement ouvertes. C'est assez ennuyeux car vous pouvez avoir un maximum de 128 sessions en attente avant que vos services ne commencent à 500 secondes.

Ceci peut être facilement reproduit (voir la réponse ci-dessous). J'étais capable d'interroger 128 SessionInitiationMessageHandlers en utilisant WinDbg. Cela pourrait donc être une bonne mesure pour identifier ce scénario.

Néanmoins, un moyen d'identifier ces clients «se conduisant mal» serait utile.

Cordialement, Alex

Source

2009-10-16 Alex

Tenet de SOA: Un service devrait besoin de rien de son clients ou d'autres services. Même si vous identifiez les clients qui se comportent mal, que feriez-vous exactement? – kd7

Très simple: je parle au développeur responsable. Ce sont des applications internes seulement. – Alex

Je suis d'accord avec vos commentaires académiques. Cependant, disons que vous êtes dans un environnement 24 heures sur 24, 7 jours sur 7 et que chaque service HTTP 500 est lancé par votre service, vous pouvez sentir comment votre bonus d'année diminue. Qu'est-ce que tu vas faire? – Alex

Puisque rien partager client et le serveur, mais les messages qui vont entre eux, il n'y a pas grand-chose que vous pouvez vraiment faire. Du côté serveur, vous pouvez consulter quelques bits d'informations envoyées par le client. Consultez la propriété OperationContext.Current dans votre méthode de service. Consultez la section MSDN documentation on OperationContext pour obtenir des informations détaillées. Par conséquent, vous pourrez peut-être enregistrer certaines informations pour identifier les clients "offensants".

Marc

Source

2009-10-17 08:38:00

Le problème est de corréler cette information: La pile WCF annule la session de veille. Il a l'information à quel client appartient cette session je suppose. La journalisation est juste un taureau. Alors disons qu'il y a un client qui vient d'ouvrir le canal, fait ses trucs RST-SCT et ne fait rien d'autre. Cela entraînera l'annulation d'une session de sécurité en attente et, pendant ce temps, le service risque fort de tomber sur "Server too busy 500's". Ce que je suis vraiment confus, c'est que manquant de fermer le client est une erreur commune dans WCF. Donc j'aurais supposé qu'il y avait un moyen intégré de résoudre ce problème. – Alex

@Alex: Je doute fortement que la pile WCF ait des informations sur l'appel du client - elle sait juste qu'il s'agit d'une session et que cette session a un délai d'inactivité, et lorsque ce délai d'inactivité est atteint, la session est simplement annulée. le client arrive, et aucune connaissance des clients n'est nécessaire ou présente –

Ainsi, vous pouvez réduire le délai d'expiration de la session dans votre cas, afin d'éliminer toutes les sessions «persistantes» plus rapidement. –

doux .... la meilleure façon de tuer un service WCF avec une conversion sécurisée semble être de ne rien faire.

ServicePointManager.ServerCertificateValidationCallback += delegate { return true; }; 

var client = new MyClient(); 
client.ClientCredentials.UserName.UserName = "user"; 
client.ClientCredentials.UserName.Password = "password"; 

while(true) 
{ 
    Console.WriteLine("OPEN"); 
     var c = client.ChannelFactory.CreateChannel(); 
    ((ICommunicationObject)c).Open(); 

     // If I comment the following line, the service throws a 
     // "Too busy, too many pending sessions" 500. 
     var request = new MyRequest { }; 
    c.Do(request); 

     // Of course I did *not* comment this line 
    ((ICommunicationObject)c).Close(); 
}

Pendant ce temps, ce bug a été confirmée par MS mais reste dans 4.x .NET même si MS dit le contraire:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499859

Source

2009-10-17 15:20:21 Alex

Identifier les clients WCF qui ne disposent pas correctement

Répondre

Questions connexes