2009-07-03 9 views
3

Ich erstelle einen Windows-Dienst, der eine Reihe von Slave-Prozessen startet. In jedem dieser Slave-Prozesse höre ich auf eine Named Pipe für eine Nachricht vom Master-Prozess.Wie kann ich prüfen, ob ein WCF-Host verfügbar ist, bevor ich einen Kanal von einem Client aus verwende?

Ich habe derzeit die Situation, in der der Master-Prozess einen Slave über eine Named Pipe anruft, bevor der Slave vollständig gestartet ist und beginnt auf die Named Pipe zu hören.

ProcessStartInfo processStartInfo = new ProcessStartInfo("slave"); 
    processStartInfo.Arguments = Address 

    Process process = new Process(); 
    process.StartInfo = processStartInfo; 

    process.Start(); 

    base.Endpoint.Binding = new NetNamedPipeBinding(NetNamedPipeSecurityMode.None); 
    base.Endpoint.Address = Address; 

    base.Channel.RemoteMethod(); 

Wenn ich dies tun wird der Kanal in CommunicationState.Faulted und alle nachfolgenden Anrufe auf dem Kanal nicht als gut.

Was kann ich tun, um vom Master zu bestätigen, dass der Slave-Prozess zu hören beginnt? Oder wie kann ich von der CommunicationState.Faulted wiederherstellen, um mein Remoteanruf erneut zu versuchen?

Antwort

1

Die einzige Möglichkeit zum Wiederherstellen des Faulted-Status besteht darin, den WCF-Client erneut zu initialisieren, indem Sie die Instanz neu erstellen und die Open() -Methode aufrufen.

Im Allgemeinen, bevor ich den Dienst anrufe, überprüfe ich immer die Eigenschaft Status und wenn es nicht geöffnet ist, versuche ich es wie ich oben beschrieben neu zu initialisieren. Wenn dies fehlschlägt, liegt ein Problem mit dem Server vor. (In meinem Fall wird der Status aufgrund von Inaktivität fehlerhaft, so dass die Initialisierung normalerweise erfolgreich ist)

+0

Wie würden Sie die Instanz neu aufbauen? Erstellen Sie eine neue Instanz des Objekts? –

+0

ja. – AlexDrenea

+0

Es brauchte einige Umstellungen von Verantwortlichkeiten zwischen Objekten, aber ich habe es jetzt eingerichtet. Danke –

0

Sie können das Ereignis "ServiceFaulted" auf dem Host anhängen und damit die Fehlerbehandlung durchführen. Laut der Dokumentation besteht die richtige Maßnahme darin, den Host abzubrechen. Sie können dann versuchen, es neu zu initialisieren, aber es kann eine sinnlose Übung sein, wenn das System nicht funktioniert.

+0

Das Problem liegt nicht im Host. Der Host wird gestartet. Das Problem liegt im Client. –

0

Vielleicht könnten Sie einen "Session" -basierten Dienst implementieren. So öffnet der Client den WCF-Kanal und ruft zum Öffnen der Sitzung auf (z. B. ein "offener" Anruf). Dies würde Ihren Gastgeber wissen lassen, dass der Slave zuhört.

Möglicherweise möchten Sie den Rückrufmechanismus von WCF untersuchen, so dass die Remote-Kommunikation mit dem Slave über einen Rückruf von dem "offenen" Anruf bereitgestellt wird, den er nach der Initialisierung durchgeführt hat.

Alex Drenea sagt richtig, dass Sie eine neue Instanz erstellen möchten. Ich würde empfehlen, einen Blick auf die ChannelFactory-Klasse in WCF zu werfen, um die Proxies zu erstellen. Sie können dies mit einigen Versuchen versuchen, das Verhalten des Slaves zu fangen. Möglicherweise möchten Sie auch eine System.Diagnostics.Debugger.Break() in Ihrem Slave-Prozess-Startup-Code platzieren, da der Debugger möglicherweise nicht anhängen, so dass Sie die Ausnahme in Ihrem Slave-Prozess nicht sehen.

Kann ich fragen, ob Sie wirklich Prozessisolation benötigen oder Synchronisation und Threads für Ihre Aufgabe ausreichen würden?

+0

Die Slave-Prozesse führen Instanzen einer Anwendung eines Drittanbieters mit einem seltsamen Verhalten aus, das wir in unserem Hauptprozess nicht wollen. Wir haben es derzeit mit Threads implementiert und verschieben es in separate Prozesse. –

+0

Gut. Ich habe ein paar Unix-Programmierer kennengelernt, die diesen Drang haben, Prozesse in Windows zu machen, und das ist in den meisten Fällen der falsche Weg. Hast du Glück mit dem Named-Pipe-Problem? – Spence