Problem mit MaxSessionsPerAddress bei Verwendung von WCF PollingDuplex und Silverlight-Client

8

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:

  • PollingDuplex-Verbindung
  • Dieses Problem kann nicht reproduziert werden, da es einmal in einer Live-Umgebung beobachtet und dann ausgeschaltet wurde, um Benutzer nicht zu beeinträchtigen
  • Das IIS-HTTPERR-Protokoll verfügt über mehrere Verbindungsabbruch-, Connection_Dropped-Einträge für einen fehlgeschlagenen Dienst

WCF-Client:

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

WCF-Server:

  • IIS Hosted
  • InstanceContextMode = PerSession
  • ConcurrencyMode = Mehrere
  • maxConcurrentCalls, maxConcurrentSessions, maxConcurrentInstances werden auf 500
  • gesetzt
  • 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"

Jede Hilfe sehr geschätzt!

    
sll 30.11.2012, 11:41
quelle

1 Antwort

0

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:

Kunde:

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:

  • Setzen Sie closeTimeout auf 10 Sekunden, damit im Falle eines Problems die Operation close in 10 Sekunden erzwungen wird, damit der Client schnell bereinigt wird
  • Zeitlimit für erneutes Verbinden von 5 Sekunden auf 30 Sekunden erhöht, damit alles, was mit alten Kanalverbindungen verbunden ist, freigegeben / bereinigt wird

Service:

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:

  • Setzen Sie sendTimeout auf 30 Sekunden, dies ist mehr als genug, um einige Kilobyte Nachrichten über das Netzwerk zu senden
sll 25.12.2012, 19:58
quelle

Tags und Links