Heute erreichte mich die Exception java.rmi.NoSuchObjectException mit der Meldung “No such object in table”. Diese Meldung habe ich zuerst nicht ganz verstanden, denn der Client hat ja zuvor über Lookup das Objekt erfolgreich geholt. Dennoch trat anschließend bei der Verwendung diese Meldung auf.
Das Problem ist jedoch so einfach wie zugleich auch etwas versteckt. Bei einem Lookup des Clients erfolgt dies auf die RMI-Registry. Diese hält die Stubs bereit und bei einem Lookup erhält der Client Informationen wie er zum eigentlichen Remote-Objekt gelangt. Der Lookup war also kein Problem. Bei der ersten Verwendung des erhaltenen Objektes wird nun eine Verbindung zum RMI-Server aufgebaut und dann das Remote-Objekt verwendet. Dies war jetzt nicht mehr da und damit kam es zu dieser Meldung. Aber warum war es nicht mehr da? Ganz einfach: Der Garbage Collector hatte es aus dem Speicher entfernt.
Die Lösung ist daher, dass die Instanz, die beim Erzeugen des UniCastRemoteObjects verwendet wird, mit gehalten werden muß, damit diese nicht vom GC entfernt wird.

RMI ist ja das Werkzeug schlechthin um verschiedene Javaprozesse miteinander kommunizieren zu lassen. Es können damit entfernte Methoden aufgerufen (Remote Method Invocation) werden, als wäre die Klasse lokal verfügbar. Da sich Java selbst um die ganze Kommunikation über TCP kümmert, hat man natürlich wenig Einflussmöglichkeiten. Betreibt man nun einen RMI-Server hinter einem NAT-Router und möchte diesen vom Internet aus zugreifbar machen, so wird einem immer wieder auf Clientseite eine Exception um die Ohren fliegen, die sagt dass das Netzwerk mit z.B. der IP 192.168.x.x nicht verfügbar wäre. Grund hierfür ist, dass der RMI-Server seine lokale IP nach außen sendet und nicht seine globale IP. Abhilfe schafft hier der Start der Applikation mit einem Parameter:

java -Djava.rmi.server.hostname=GLOBALEIP ...

Ab jetzt sendet der Server die globale IP als Hostnamen und ein Zugriff von Außerhalb ist problemlos möglich.