# RMI Client abmelden?



## Tallan (21. Sep 2009)

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 (21. Sep 2009)

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 (21. Sep 2009)

tuxedo hat gesagt.:


> 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.
> 
> ...




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 (21. Sep 2009)

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 (21. Sep 2009)

tuxedo hat gesagt.:


> 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 (21. Sep 2009)

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 (21. Sep 2009)

tuxedo hat gesagt.:


> 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.
> ...



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 (21. Sep 2009)

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



			
				http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/server/UnicastRemoteObject.html#UnicastRemoteObject%28int%29 hat gesagt.:
			
		

> protected UnicastRemoteObject(int port)
> throws RemoteException
> 
> Creates and exports a new UnicastRemoteObject object using the particular supplied port.
> ...



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


----------

