Frage

Ich habe eine WCF-Client / Server-Anwendung, die HTTP kommuniziert über den WSHttpBinding verwenden.

Server-Setup : Selbst Hosting, den Standard WCF ServiceHost verwenden. Meine eigentliche Dienstklasse zugeschrieben als:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, 
 InstanceContextMode = InstanceContextMode.PerSession, 
 UseSynchronizationContext = false)]

Client-Setup : eine visuell-Studio erzeugt Client-Proxy mit Synchron Service-Anrufe (. proxy.call_server_method blockiert, bis zu dem Zeitpunkt, als der Server vollständig reagiert hat)

Szenario : Ich habe einen bestimmten Methodenaufruf, die 20 Sekunden dauern, auf dem Server auszuführen. Der Client ruft diese Methode in einem separaten Thread, so ist es nicht gehalten wird, und die ConcurrencyMode.Multiple bedeutet WCF es in einem separaten Thread auf dem Server als auch ausgeführt werden soll.

Diese Theorie durch die Tatsache gestützt, dass, wenn ich meine App konfigurieren NetTcpBinding zu verwenden, funktioniert alles einwandfrei.

Problem :
Wenn ich die App konfigurieren WSHttpBinding zu verwenden, dann ist diese lange Methodenaufruf bewirkt, dass die HTTP-Anfragen zu ‚back up‘. Ich habe dieses Verhalten überprüft sowohl von meinen Logs Inspektion und durch die HTTP-Requests Debuggen Fiedler verwenden.

Beispiel:

  • Client leitet 20-Sekunden langen Anfrage auf einem Hintergrund-Thread
  • Client initiiert Anforderung B und C auf den Vordergrund Gewinde
  • Anfragen B und C an den Server gesendet bekommen, die sie nicht verarbeiten, bis es mit dem 20-Sekunden langen Anfrage
  • erfolgt

Aber manchmal:

  • Anfragen B und C wird nicht gesendet (sie scheinen nicht einmal in Fiedler), bis die 20-Sekunden-Anfrage zurück kommt (das ist selten).
    • Hinweis: Einstellung <add address="*" maxconnection="100"/> in der app.config des Kunden machte diese (scheinbar) stoppen geschieht
    • .
  • Anforderung B wird sofort eine Antwort gesendet und empfängt, während Anfrage C bis zur 20-Sekunden zurückgehalten wird eine vollendet (dies ist selten)

Hier ist eine Zeitleiste von Fiedler demonstriert das Problem: (klicken für größere Version)

Wie Sie sehen können, werden die Anfragen alle immer auf dem Server gesichert. Nachdem der 20-Sekunden-Anforderung abgeschlossen ist, werden alle Antworten kommen Überschwemmungen durch, aber beachten Sie, dass es einige Anfragen sind, die nicht immer gehalten ...

So Fragen :

  • Was zum Teufel geht hier vor? Warum es funktioniert fein NetTcpBinding mit und nicht arbeiten WSHttpBinding mit?
  • Warum das inkonsistente Verhalten?
  • Was kann ich tun, um es zu beheben?

Weitere Informationen:

  • Es ist nicht auf dem Server sperren. Ich habe Haltepunkte zu setzen und verwendet !syncblk und meldet es konsequent keine Sperren gehalten werden.
  • Es ist nicht mein Threading (NetTcpBinding sollte nicht anders arbeiten)
  • Ich habe in den Server app.config <serviceThrottling maxConcurrentCalls="1000" maxConcurrentInstances="1000" maxConcurrentSessions="1000" /> gesetzt
  • Der 20-Sekunden-Anruf nur auf einem Timer wartet, es ist nicht die CPU oder Festplatte oder im Netzwerk Dreschen
  • Ich würde eine Lösung bevorzugen, die nicht zur Wieder Architecting die Anwendung beinhalteten asynchrone Aufrufe zu verwenden ... es ist ein großer Haufen von Legacy-Code und ich mag wirklich nicht mit Sachen zu verwirren Ich verstehe nicht, .
War es hilfreich?

Lösung 3

[Selbst Antwort andere Benutzer zu zeigen, was unsere Lösung war,]

Am Ende habe ich es nie geschafft, dieses Problem zu lösen.
Unsere letzte Lösung war unsere App wechseln weg von WSHttpBinding und auf NetTcpBinding in der Produktion - wir schließlich ohnehin aus Performance-Gründen hatten auf dies zu tun Planung

.

Das ist ziemlich obwohl bedauerlich, da es eine schwarze Markierung auf WSHttpBinding Blätter, die nicht gerechtfertigt werden können oder nicht. Wenn jemand schon einmal mit einer Lösung kommt, die bis beinhaltet nicht WSHttpBinding Notwasserung, würde ich gerne darüber weiß

Andere Tipps

Es gibt einige Drossel außerhalb von WCF (a .NET oder Windows Sache), dass standardmäßig nur maximal zwei gleichzeitiger ausgehenden HTTP-Verbindungen im Stich gelassen. Leider kann ich nicht für das Leben von mir den Namen der Sache (und was Sie in app.config oder Ihre App setzen würden es außer Kraft zu setzen) erinnern. In Anbetracht, dass man nicht die Anfragen lassen den Client zu sehen, und dass es nur HTTP, ich glaube, Sie schlagen „das Ding“. Ich halte für seinen Namen suchen.

Update: Fand es - versuchen, dies auf dem Client (aber die '2' zu einer größeren Zahl aus):

<configuration>
  <system.net>
    <connectionManagement>
      <add address = "*" maxconnection = "2" />
    </connectionManagement>
  </system.net>
</configuration>

Wir sahen genau die gleichen Symptome, die mit einem JSON-Dienst in IIS / ASP.NET gehostet werden.

Die Ursache beendet die Anfragen sind ASP.NET die Synchronisation von bis - nicht WCF. Wir mussten Sitzungszustand (auf der Anwendungsebene) deaktivieren gleichzeitige WCF Methoden zu erhalten.

Web.config: <system.web> <sessionState mode="Off" /> </system.web>

Bitte beachten Sie, dass unser Dienst verwendet webHttpBinding, nicht WSHttpBinding. Also, ich bin nicht sicher, ob dies auch Orion Problem löst.

Ich glaube, Sie das Protokoll Grenze getroffen und um es Ihnen zu arbeiten, müssen Sie die Standardeinstellungen auf dem Clientcomputer ändern:

http://support.microsoft.com/kb/183110

http://support.microsoft.com/kb/282402

Ich denke, WSHttpBinding verwendet WinINET Einstellungen, wenn die Anforderungen Ausgabe.

Wenn Sie Basichttpbinding ändern, funktioniert es?

Ist ja, es klingt wie das ist Ihr Problem , Drosselung Session, etwas, das mich in den Arsch gebissen.

Betrachten ConcurrencyMode.Multiple auf per-Call-Dienste gleichzeitig zu ermöglichen, nennt.

ich vergessen - es könnte der Bestellung werden? Ich denke, vielleicht RM über http bewahrt, um aber vielleicht TCP-Sitzungen nicht (es sei denn, Sie explizit anfordern es)? Gibt es ein Attribut auf dem Servicevertrag, die bestellt beschriebenen / ungeordnete Sitzungen (I vergessen).

Nicht sicher, aber manchmal ist das Problem mit den gleichzeitigen Anrufen von Silverlight-Anwendung mit Browser-Verbindung Management. Für mich war die Lösung, die in unserem App.xaml.cs, Application_Startup Methode als descrive setzt hier: http://weblogs.asp.net/olakarlsson/simultaneously-calling-multiple-methods-on-a-wcf-service-from-silverlight

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top