WCF-client-Deadlocks aufgrund callback-auch wenn callback IsOneWay

neuen WCF.

Ich habe einen client, der Deadlocks beim Aufruf einer WCF-Dienst.

Den service aufrufen, die einen Rückruf an den client an der Uhrzeit des Anrufs, die gekennzeichnet ist als IsOneWay. Ich habe bestätigt, dass der Dienst nicht blockiert, auf den Rückruf.

Client ruft sofort den gleichen service wieder (in einer engen Schleife), ohne doch den Rückruf gewartet. Der client wird dann von deadlocks (und einen Haltepunkt auf der service-Seite wird nie ausgelöst).

So zur Erinnerung: 

CLIENT                                SERVICE
Call service -----------------------> (service breakpoint triggers)
(waiting for dispatch thread) <------ Invoke callback (IsOneWay - doesn't block)
                                      Service returns

Call service again immediately -----? (service breakpoint doesn't trigger)
(deadlock)

Gehe ich davon aus, dass der Rückruf hat packte einige WCF-Sperre auf der client-Seite, und dann die zweite service-Aufruf von der client-will auch, dass sperren, so deadlock Ergebnisse. Aber das ist nur Vermutung.

Ich gelesen habe ConcurrencyMode aber ich kann mich nicht entscheiden, welcher Modus zu verwenden ist, oder wo es, da bin ich mir nicht 100% klar, was Los ist, und was blockiert wird, genau.

Ich würde auch lieber halten Sie alle Rückrufe, die verarbeitet werden, indem die dispatch-thread wenn möglich, wie es hält den code einfacher.

Kann ein WCF-Experten ein Licht auf genau das, was ist hier Los?

Vielen Dank

  • Können Sie zeigen Sie uns den code?
  • Kaum Wert, es gibt nichts zu es. Es ist eher ein problem von mir zu verstehen, wie WCF befasst sich mit und synchronisiert Rückrufe.
  • Welche Art der client-Anwendung haben Sie? Sind sowohl client-als auch call-und callback-Wege, oder einer von Ihnen mit der Antwort?
InformationsquelleAutor GazTheDestroyer | 2011-06-08
  1. 21

    OK, ich glaube ich habe es sussed es.

    WCF-Dienste, die standardmäßig auf single threaded. Alle Anrufe und Rückrufe bekommen gemarshallt, um einen einzelnen thread (oder SynchronizationContext um genauer zu sein).

    Meine app ist eine single-threaded-WPF-Anwendung, so dass die SynchronizationContext-festgelegt wird, um die dispatch-thread.

    Wenn der Rückruf kommt, in der er versucht, Marschall der Aufruf der dispatch-thread, das ist natürlich sa-Blockierung auf der original-service-Aufruf. Ich bin mir nicht klar, es sperrt genau, aber es gibt offensichtlich einige Globale Sperre, die es versucht, sich vor dem warten auf die dispatch-thread.

    Wenn der dispatch-thread ruft dann den service wieder, es deadlocks auf diese Globale Sperre.

    Zwei Möglichkeiten um ihn herum:

    1) Erstellen Sie den service-proxy auf einem anderen thread in den ersten Platz. Alle Anrufe erhalten gemarshallt über diesen thread statt-und es wird nicht egal, dass der dispatch-thread blockiert ist.

    2) [CallbackBehavior(UseSynchronizationContext = false)] - Attribut der client-Klasse implementiert die callback. Dies bedeutet WCF ignorieren die synchronisation Kontext, wenn der Rückruf kommt, und es wird der service auf jedem verfügbaren thread.

    Ging ich mit 2. Offensichtlich bedeutet dies, ich muss Marschall Rückrufe, könnte ein update des GUI, um die dispatch-thread selbst, aber zum Glück ist meine callback-Implementierung ist ein kleiner wrapper, wie auch immer, ich mache nur einen _dispatcher.BeginInvoke() in jedem callback-Methode marshal ASYNCHRON. Der dispatch-thread wird dann service, wenn Sie eine chance bekommt, die ist, was ich wollte in den ersten Platz.

    • [CallbackBehavior(UseSynchronizationContext = false)] war die Antwort in meinem Fall. Ich habe auf der Suche für eine Lösung, die ganzen Tag, und endlich habe ich das gefunden. Danke.
    • Froh, dass es jemandem geholfen, cheers.
    • Einen Dritten Weg: Sie können die SynchronizationContext auf die InstanceContext verwendet, um das DuplexChannelFactory. Wenn er auf einer Ebene new SynchronizationContext() funktioniert einwandfrei.
    • Dies gilt für WinForms zu. Auch, seien Sie vorsichtig, um anzugeben, **CallbackBehavior**(UseSynchronizationContext:=False), - Einstellung **ServiceBehavior**(UseSynchronizationContext:=False) ist zulässig, hat aber keine Auswirkung
    InformationsquelleAutor GazTheDestroyer
  2. 0

    Der Reihenfolge, in der Sie dargestellt, ähnelt einem synchronen Aufruf. Während in der einen asynchronen Aufruf, die Reihenfolge wäre:

    Client                            Server
Call service    --------------->ProcessRequest(1) //Your for loop for instance.
Call service    --------------->ProcessRequest(2)
Call service    --------------->ProcessRequest(3)
Call service    --------------->ProcessRequest(4)
Call service    --------------->ProcessRequest(5)

Callback awake  <---------------Response1 //Responses tends to pour in...
Callback awake  <---------------Response2
Callback awake  <---------------Response3
Callback awake  <---------------Response4...

    In jedem Fall von jedem asynchronen web-service-Aufruf, erzeugt das system einen separaten IO-thread(IOCP-thread), und verarbeitet die Anfrage. In diesem, nur selten finden Sie eine Sackgasse.

    Habe ich so gefunden, auch wenn der Aufruf innerhalb einer Schleife zu arbeiten, sehr gut.

    Können Sie, zum Beispiel, für die Veranstaltung anmelden .OnProcessComplete, und rufen Sie dann die ProcessCompleteAsync Methode.

    • Ich will nicht async Aufrufe wenn. Ich hoffte, dass die Rückrufe würde nur Schlange in ähnlicher Weise auf Ihr Diagramm, und ich konnte Sie Dienst in der dispatch-thread wenn ich die chance hatte. Bin immer das Gefühl, das ist nicht möglich wenn. :/
    • Rückrufe asynchrone Aufrufe. Ein callback ist, wenn Sie Anfrage für Benachrichtigungen(Ereignisse, zum Beispiel); dann sind Sie mitgeteilt, in der form, dass Ihre Methode/Funktion wird wieder aufgerufen.
    • Sorry, ja, die Rückrufe sind offensichtlich async. Sie schien Herleitung oben, dass ich konvertieren Sie die ursprüngliche service-Aufrufe asynchrone, so dass der dispatch-thread frei ist.
    • Sie Sprachen über callback, so ist der Grund der Herleitung von asynchrone Aufrufe. Wenn Sie wollen synchrone Aufrufe können Sie Einblick in die Implementierung des producer/consumer-pattern. Zum Beispiel, Ihre ProcessRequest(1) wird die push-operation an eine Warteschlange, und ein thread wird Dequeue ein Element, zu verarbeiten und zu reagieren. Oder enqueue-fordert, um eine threadpool worker-threads, die direkt von der WCF-Betrieb mit asynchronen Delegaten; und gesetzt threadpool basierte Zeitgeber aus Ihrer WCF-Betrieb.
    InformationsquelleAutor KMån
Schreibe einen Kommentar