Problème de MaxSessionsPerAddress lors de l'utilisation de WCF PollingDuplex et du client Silverlight

Question

Les journaux de trace de WCF montrent beaucoup "The server has hit a PollingDuplex throttle, MaxSessionsPerAddress, and cannot accept another session from this client. An http error was returned" erreurs.

Je ne trouve pas assez de détails sur MaxSessionsPerAddress les paramètres, je viens de trouver ce poste qui dit que MaxSessionsPerAddress c'est toujours 10 et ne peut être modifié.

Je pense simplement que ce problème peut être lié à une logique de tolérance aux pannes que j'ai mise en œuvre pour le proxy client qui, avec un certain délai d'attente, entraîne un tel problème : En cas d'échec du canal, le proxy client WCF ferme un canal (Close() puis Aboort() dans try/catch) et essaie ensuite de se reconnecter toutes les 5 secondes, N tentatives. Peut-être un client n'était pas capable de se connecter même après 10 tentatives ce qui a créé 10 sessions sur un service donc toutes les tentatives suivantes ont été refusées ?

Informations générales :

• Connexion polluanteDuplex
• Impossible de reproduire ce problème, car il a été observé une fois dans un environnement réel, puis désactivé pour ne pas affecter les utilisateurs.
• Le journal IIS HTTPERR comporte plusieurs entrées Connection_Abandoned, Connection_Dropped pour un service qui a échoué.

Client WCF :

• Silverlight4
• ClientPollTimeout=5min
• InactivityTimeout=24h, SendTimeout=30min, CloseTimeout=3min
• ReceiveTimeout=24h, OpenTimeout=3min

Serveur WCF :

• IIS hébergé
• InstanceContextMode = PerSession
• ConcurrencyMode = Multiple
• maxConcurrentCalls, maxConcurrentSessions, maxConcurrentInstances sont fixés à 500
• HttpBinding, httpTransport, PollingDuplexBindingElement, DuplexChannelFactory
• sendTimeout="00:30:00", receiveTimeout="24:00:00", openTimeout="00:10:00", closeTimeout="00:10:00"
• maxOutputDelay="00:00:01", inactivityTimeout="24:00:00", serverPollTimeout="00:02:00"
• maxReceivedMessageSize="1073741824", maxBufferSize="1073741824", MaxBufferPoolSize="2147483647"

Toute aide est la bienvenue !

Answer 1

La raison principale était qu'un client a été éventuellement échoué qui force un client à se reconnecter trop souvent (chaque 5 secondes), après la reconnexion un serveur/service reçoit une demande de client mais le client encore a été échoué, chaque reconnexion a créé une nouvelle session de service de WCF qui terminera seulement dans 2 minutes de l'absence d'interrogation de client, ainsi dans 2 minutes un client a créé trop de sessions du côté de service.

Pourquoi un client silverlight a fini par tomber en panne et se déconnecter ? Voir le post suivant qui décrit un problème réel et une solution : Le client WCF Silverlight obtient une réponse 404 not found pour un message de sondage.

D'autres questions et solutions, qui ont été appliquées, peut-être que quelqu'un a trouvé utile :

Client :

Question : Pour différentes raisons, l'opération de fermeture du canal peut être bloquée pour CloseTimeout="00:03:00" minutes ce qui est trop long

Solution :

• Définir closeTimeout à 10 secondes pour qu'en cas de problème, l'opération de fermeture soit forcée dans les 10 secondes pour que le client fasse le nettoyage rapidement.
• Augmentation du délai de reconnexion de 5 à 30 secondes pour permettre à tout ce qui est lié à l'ancienne connexion de canal d'être libéré/nettoyé.

Service :

Question : Parfois, j'ai vu que le service est bloqué alors qu'une invocation d'un callback client ( CallbackContract ) pour sendTimeout=30minutes parce qu'il n'est pas possible de terminer l'opération en raison d'un client déconnecté/en panne, ce qui retarde le nettoyage du service de plusieurs jours. 30 minutes mais doivent être aussi rapidement que possible libérés/nettoyés et éliminés en cas de client défaillant/déconnecté

Solution :

• Définir sendTimeout à 30 secondes, ce qui est plus que suffisant pour envoyer un message de quelques kilobytes sur le réseau.