WCF-Ablaufverfolgungsprotokolle zeigen viele "The server has hit a PollingDuplex throttle, MaxSessionsPerAddress, and cannot accept another session from this client. An http error was returned"
-Fehler.
Sie können nicht genügend Details zu MaxSessionsPerAddress
-Einstellungen finden, die Sie einfach gefunden haben dieser Post , der besagt, dass MaxSessionsPerAddress
immer 10
ist und nicht geändert werden kann.
Ich denke nur, dass dieses Problem mit einer Fehlertoleranzlogik zusammenhängt, die ich für einen Clientproxy implementiert habe, was zusammen mit einem Timeout zu folgendem Problem führt: Im Falle eines Kanalfehlers schließt der WCF-Clientproxy einen Kanal (Close () und dann Abort) () in try / catch) und versucht dann alle 5 Sekunden, N Wiederholungen erneut zu verbinden. Vielleicht war ein Client nicht in der Lage, selbst nach 10 Wiederholungen eine Verbindung herzustellen, was 10 Sitzungen auf einem Dienst erzeugte, so dass alle nächsten Versuche abgelehnt wurden.
Allgemeine Informationen:
WCF-Client:
WCF-Server:
Jede Hilfe sehr geschätzt!
Der Hauptgrund war, dass ein Client schließlich fehlgeschlagen ist, was einen Client zwingt, sich zu oft neu zu verbinden (alle 5 Sekunden), nachdem ein Server / Dienst eine Clientanforderung erneut erhält, aber der Client erneut fehlgeschlagen ist, erstellte jede erneute Verbindung eine neue WCF Dienstsitzung, die nur in 2 Minuten Abwesenheit des Clientabrufs beendet wird, so dass ein Client in 2 Minuten zu viele Sitzungen auf der Dienstseite erstellt hat.
Warum wurde ein silverlight-Client möglicherweise fehlerhaft und getrennt? Siehe folgenden Beitrag, in dem ein tatsächliches Problem und eine Lösung beschrieben werden: WCF Silverlight-Client erhält 404 nicht gefunden Antwort für Umfrage-Nachricht
Andere Probleme und Lösungen, die angewendet wurden, fand vielleicht jemand hilfreich:
Problem: Aus verschiedenen Gründen kann die Funktion zum Schließen eines Kanals für CloseTimeout="00:03:00"
minutes festhalten, was zu lang ist
Lösung:
closeTimeout
auf 10 Sekunden, damit im Falle eines Problems die Operation close in 10 Sekunden erzwungen wird, damit der Client schnell bereinigt wird Problem: Manchmal sah ich, dass der Dienst bei einem Client-Callbackaufruf ( CallbackContract
) für sendTimeout=30minutes
hängen geblieben ist, weil der Vorgang aufgrund des getrennten / fehlerhaften Clients nicht abgeschlossen werden konnte, sodass die Dienstbereinigung für% co_de verzögert wurde % Minuten, sollte aber so schnell wie möglich freigegeben / bereinigt und entsorgt werden im Falle eines fehlerhaften / getrennten Clients
Lösung:
30
Sekunden, dies ist mehr als genug, um einige Kilobyte Nachrichten über das Netzwerk zu senden Tags und Links wcf c# silverlight .net-4.0 polling