RMI Client abmelden?

[Tallan]

Hallo Zusammen,

ich habe eine generelle Frage zu RMI

Ich habe einen Client der dem Server ein Remote Object zur verfügung stellt.

public class ClientInterfaceImpl extends UnicastRemoteObject implements ClientInterface
{
	

	public ClientInterfaceImpl(int PORT) throws RemoteException
	{
        super(PORT,
                new SslRMIClientSocketFactory(),
                new SslRMIServerSocketFactory());
	}

....
}


public interface ClientInterface extends Remote
{
..
}



// Der Server wird wie folgt eingebunden

serverInterface = (ServerInterface)registry.lookup("Server");

ClientInterfaceImpl wird als InterfaceObjet dem Server übergeben um ein callBackObject zu realisieren.

Meine Frage wäre jetzt :
Auf was muß ich achten wenn ich den Client richtig beenden möchte.
Muss die Verbindung explizit gelöst werden?
Was passiert mit Objekten die auf dem Server noch referenziert sind?

 

[tuxedo]

Bei RMI gibts den DGC -> Distributed Garbage Collector. RMi kümmer sich selbstständig um das abräumen von nicht mehr gebrauchten Remote-Objekten.

Das mag auf den ersten Blick einfacher wirken als irgendwo auch noch "disconnect()" oder "release()" aufrufen zu müssen. Aber in manchen Konstellationen bringt es mehr verwirrung wie Vorteile.

Ein RMI-Server läuft i.d.R. solange, wie das Remote-Objekt in der Registry gebunden ist.

Schau mal nach ob du zur "bind()" Methode auch ein "unbind()" findest. Das sollte dich weiterbringen.

- Alex

 

[Tallan]

Bei RMI gibts den DGC -> Distributed Garbage Collector. RMi kümmer sich selbstständig um das abräumen von nicht mehr gebrauchten Remote-Objekten.

Das mag auf den ersten Blick einfacher wirken als irgendwo auch noch "disconnect()" oder "release()" aufrufen zu müssen. Aber in manchen Konstellationen bringt es mehr verwirrung wie Vorteile.

Ein RMI-Server läuft i.d.R. solange, wie das Remote-Objekt in der Registry gebunden ist.

Schau mal nach ob du zur "bind()" Methode auch ein "unbind()" findest. Das sollte dich weiterbringen.

- Alex

bind und unbind beziehen sich ja auf den server, den möchte ich garnicht beenden.
Es geht mir nur darum den Client "sauber" zu beenden so das der Server nicht auf dauer immer mehr unnötige Objekte ansammelt.
Was die Sessionverwaltung und CallbackObjekte angeht habe ich mich bereits darum gekümmert das diese "einträge" vom Server verschwinden, es geht jetzt eigentlich nur darum ob die Verbindung noch gesondert gelöst werden muß aber wenn das der DGC erledigt sollte das damit ja erledigt sein.

 

[tuxedo]

Du verstehst nicht: Wenn der Client via RMI-Servertechnik auch ein Remote-Objekt anbietet (die Sache hatten wir ja shcon diskutiert), dann müsstest du, wenn der Client sich beenden soll, auch dieses Remote-Objekt aus der eigenen Registry entfernen. Und das geht via unbind().

Wenn du auf dem Client keinen RMi-Server startest, dann gibts nix weiter zu beachten außer dass Remote-Objekte in keiner Liste mehr vor sich hingammeln und vom GC nicht abgeräumt werden können. Einen "Verbindung zum Server trennen" Befehl gibt es nicht.

- Alex

 

[Tallan]

Du verstehst nicht: Wenn der Client via RMI-Servertechnik auch ein Remote-Objekt anbietet (die Sache hatten wir ja shcon diskutiert), dann müsstest du, wenn der Client sich beenden soll, auch dieses Remote-Objekt aus der eigenen Registry entfernen. Und das geht via unbind().

Wenn du auf dem Client keinen RMi-Server startest, dann gibts nix weiter zu beachten außer dass Remote-Objekte in keiner Liste mehr vor sich hingammeln und vom GC nicht abgeräumt werden können. Einen "Verbindung zum Server trennen" Befehl gibt es nicht.

- Alex

Ich starte auf dem Client keinen "Server" mehr, ich übergebe dem Server ein CallbackObjekt welches von UniCastRemoteObj erbt und überge diesem die Portnummer

public class ClientInterfaceImpl extends UnicastRemoteObject implements ClientInterface
{
    
 
    public ClientInterfaceImpl(int PORT) throws RemoteException
    {
        super(PORT,
                new SslRMIClientSocketFactory(),
                new SslRMIServerSocketFactory());
    }
...

Damit wird kein selbst implementierter Server auf der Client-Seite für den RMI Call vom Server auf den Client benötigt. ( Wird wohl von der VM selbst gehandelt )

 

[tuxedo]

D.h. du hast rausgefunden wie man RMi-Callback-Objekten vorab einen Port verpasst?
Wäre ja schonmal ein Anfang 🙂

Aber auch in diesem Fall reicht es sicherzustellen, dass keiner mehr eine Referenz auf ein Remote-Objekt (seit es nun Server.Objekt oder Callback) hat. Der DGC und GC räumen dann auf und trennen ggf. die Verbindung.

- Alex

 

[Tallan]

D.h. du hast rausgefunden wie man RMi-Callback-Objekten vorab einen Port verpasst?
Wäre ja schonmal ein Anfang 🙂

Aber auch in diesem Fall reicht es sicherzustellen, dass keiner mehr eine Referenz auf ein Remote-Objekt (seit es nun Server.Objekt oder Callback) hat. Der DGC und GC räumen dann auf und trennen ggf. die Verbindung.

- Alex

Jap, bidirektion ist damit zwar nicht möglich aber immerhin etwas.
Um mich mit dem Thema etwas zu beschäftigen habe ich am Wochende mal die Beispiele mit RMI und Firewall mal durchgetestet.

 

[tuxedo]

jetzt wo ich die ApiDoc mal genaue lese (bin nie auf die Idee gekommen die von UnicastRemoteObject zu studieren) wird mir einiges klar:

protected UnicastRemoteObject(int port)
throws RemoteException

Creates and exports a new UnicastRemoteObject object using the particular supplied port.

Parameters:
port - the port number on which the remote object receives calls (if port is zero, an anonymous port is chosen)

Ist RMI ja doch nicht sooo doof. Aber bidirektionale Kommunikation ist für Internetanwendungen halt doch geschickter ;-)