Warum läuft mein C # Remoting-Objekt ab, auch wenn die Lebensdauer Null zurückgibt?

8

Dies ist ein letzter Ausweg nach vielen Tagen Googeln, um zu versuchen, eine definitive Antwort auf meine Frage zu finden.

Ich habe einen Windows-Dienst, ein Windows-Formular und ein Remoting-Objekt (alle in C #) erstellt. Ich verwende das Remoting-Objekt, um mithilfe von Ereignissen zwischen dem Dienst und dem Formular zu kommunizieren.

Hier ist ein vereinfachtes Beispiel für die typische Interaktion zwischen den Objekten:

  • AdminForm ruft RemoteObjects Methode RequestLoadForm ()
  • auf
  • RemoteObject löst ein Ereignis aus, auf das AdminService wartet
  • AdminService wird über das Ereignis benachrichtigt und ruft LoadFormData (Zeichenfolgedaten) auf dem RemoteObject auf
  • RemoteObject löst ein Ereignis aus, auf das AdminForm wartet
  • AdminForm wird über das Ereignis benachrichtigt und kann mithilfe der Zeichenfolgendaten Werte für die Steuerelemente AdminForm festlegen

Das alles funktioniert gut, alles interagiert wunderbar für die ersten 5 Minuten oder so. Danach wird die Verbindung zwischen den Objekten irgendwie getrennt, und ich kann nicht mehr zwischen Objekten kommunizieren.

Der erste Versuch, das Problem zu beheben, bestand darin, die InitializeLifetimeService-Methode zu überschreiben, um null zurückzugeben. Dies hat nicht geholfen (obwohl es zukünftige Mietprobleme vermeiden könnte).

Der zweite Versuch bestand darin, meine AdminForm und AdminService ISponsoren des RemoteObject zu erstellen und sie so einzurichten, dass die Lease für das Objekt verlängert wird. Noch einmal, das Problem wurde nicht behoben.

In meinen verschiedenen googlings habe ich jemanden gefunden, der etwas über Eventhandler erwähnt, die Müll gesammelt werden. Ich bin nicht sicher, ob das das Problem ist oder nicht, aber ich dachte, ich würde es erwähnen.

Dies ist der Fehler, der auftritt, nachdem die Verbindung für & gt; 5 Minuten:

System.Runtime.Remoting.RemotingException wurde vom Benutzercode
nicht behandelt   Nachricht="Angeforderter Dienst nicht gefunden"
  Source="System.Runtime.Remoting"

Nun, das Seltsame daran ist, dass es auf der Seite AdminService auftritt. Das AdminForm ruft die Methode für RemoteObject auf. Dadurch wird das Ereignis ausgelöst, und dann sieht AdminService dieses Ereignis und versucht, die LoadFormData-Methode (String-Daten) des RemoteObject aufzurufen, und an dieser Stelle wird die Ausnahme ausgelöst .

Ich bin völlig erschöpft von Google-Suchen, da ich nicht finden kann, was ich brauche, um es zu reparieren.

    
Matt P 26.05.2011, 02:35
quelle

5 Antworten

3

Ich stehe vor einem ähnlichen Problem. Ich hoffe, dass die folgende Beobachtung und Lösung für jemanden mit ähnlichen Problemen geeignet ist.

Objekt A kommuniziert mit Objekt B über die App-Domäne, während Objekt B über Ereignishandler zu Objekt A zurückruft. Sowohl Objekt A als auch B erben von MarshalByRefObject, um gegenseitigen Aufruf über die App-Domäne zu ermöglichen.

Objekt B überschreibt InitializeLifeTimeService, um für unbegrenzte Lease null zurückzugeben. Die Verbindung ist jedoch nach dem Start des Programms noch ca. 5 Minuten abgelaufen (Remoting-Standard-Anfangsleasingzeit).

Eine wichtige Beobachtung ist, dass der Aufruf von Objekt A weiterhin erfolgreich ausgeführt wird, aber wenn Objekt B zurückruft, wird die Ausnahme für Objekt B ausgelöst. Offensichtlich ist der Verbindungsablauf für den Rückruf-Proxy von Objekt A nicht erfolgt anders herum, wie wir dachten.

Daher, schnelle Antwort, stellen Sie sicher, dass sowohl Objekt A als auch B den InitializeLifeTimeService überschreiben, um null zurückzugeben. Das wird das Problem lösen, zumindest für meinen Fall.

Nur ein paar zusätzliche Sachen, wenn eine Verbindung abgelaufen ist, bedeutet das nicht, dass das verbundene Objekt Müll gesammelt wird. Der Lease-Ablauf bewirkt, dass der Proxy getrennt wird, das tatsächliche Objekt jedoch möglicherweise weiterhin in der jeweiligen App-Domäne vorhanden ist. Wenn Sie den Ablauf des Leasingverhältnisses mit dem Objekt gleich halten, kann es sein, dass Sie das gesamte Bild nicht sehen können.

    
weltall17 01.10.2014 14:44
quelle
2

sollte überschrieben werden:

%Vor%     
Peter 31.08.2011 07:45
quelle
1

Sie können statische Eigenschaften von System.Runtime.Remoting.Lifetime.LifetimeServices auf der Serverseite festlegen:

%Vor%

aber ich bevorzuge Leasing / Sponsoren (auf Kundenseite)

Ссылка

%Vor%

Wenn Sie weitere Probleme beim Marshalling haben, verwenden Sie den System.Runtime.Remoting.Services.TrackingServices-Namespace Ссылка

    
pg0xC 03.09.2011 18:40
quelle
0

Sie sollten die Methode InitializeLifeTimeService () <überschreiben / a> nicht GetLifetimeService () zu Zurückgeben von null.

%Vor%

Dann sollte das Objekt remove eine endlose Lebensdauer haben.

    
Jehof 26.05.2011 05:47
quelle
0

Dies kann mehrere Gründe haben.

  • Möglicherweise überschreiben Sie InitializeLifetimeService am falschen Objekt. Durchsuchen Sie Ihren Quellcode nach allen Erwähnungen von MarshalByRef und geben Sie jedem einen langen, harten Blick.

  • Die unendliche Lease dauert nur bis die Anwendungsdomäne entladen ist. Durchsuchen Sie Ihren Quellcode nach allen Erwähnungen von Unload und geben Sie jedem, der eine AppDomain entlädt, einen langen, harten Look.

  • Die AppDomain könnte mit einem Prozess, der wie der Neustart eines Win32-Dienstes beendet wird, erneut geladen werden. Es kann auch durch Code von Drittanbietern entladen werden, wenn Ihr Server auf einer Art von Anwendungsserver bereitgestellt wird und ein Bereitstellungsvorgang oder eine Fehlerwiederherstellung das Neuladen auslöst. Untersuchen Sie Protokolle von Drittanbietern, um Beweise dafür zu finden.

  • Fügen Sie ausreichend Protokollierung hinzu und untersuchen Sie die Exception-Stack-Traces sorgfältig, um sicher zu gehen, dass Sie nicht zu einem Serverobjekt eines Drittanbieters (möglicherweise über Ihr eigenes unendliches Lease-Serverobjekt) oder zu einer älteren Version aufrufen von Ihrem eigenen Code geladen von wer weiß wo, so dass die Quellcode-Forschung oben könnte es vermissen.

Ich habe gerade die Recherche zu einem Vorfall abgeschlossen, der sich als Kombination des ersten und letzten Punktes meiner Liste herausstellte.

    
Jirka Hanika 30.01.2018 08:23
quelle