COMP 310
Spring 201
7

Lec39: RMI Garbage-Collecting and Final Project Issues

Home  Info  Canvas   Java Resources  Eclipse Resources  Piazza

See the Comp310 WWJ web page!

Project Proposal Issues

API Questions

What is the timeline for getting the API ready?

 

 

RMI Garbage-Collecting Trap!

An important discovery was made by a fellow student concerning the way that RMI does garbage-collecting.    One would naturally believe that when a Remote object is exported, the resulting skeleton object would retain a reference to the Remote object, thus, so long as the skeleton remained around and in use, the Remote object would not get garbage-collected because some other object is still using it.

The problem is that the skeleton is really all by itself after the stub is shipped off.   There is technically no direct link between the stub and the skeleton so even if the stub is retained locally, the skeleton has no references to it.   RMI implements "distributed garbage collection", a topic too complex to go into detail here, but suffice it to say that RMI tries but can be unsuccessful in determining if anyone really is still using a stub+skeleton+Remote object anymore.    That means for a RMI program without the proper safeguards, Remote objects can looks like they suddenly disappear as the RMI subsystem garbage collects them.

Since the timing of the garbage collection depends on many, many factors including what the user and program is doing and even the machine on which the program is running, the symptoms of this issue are difficult to nail down isolate because they may manifest themselves as erratic, non-reproducible behavior with errors messages such  "Object not in table" and "Connection refused".  

Here is a classic example of problematic code:

IMyRemoteInterface connStub = (IMyRemoteInterface ) UnicastRemoteObject.exportObject(new IMyRemoteInterface(){
		// methods, fields, etc
	}, aPort); 

There is no reference in the program to the anonymous inner class above, so it is very possible that the RMI subsystem will garbage-collect it at some point, causing anyone's usage of the connStub to fail unexpectedly.

Work-arounds:

 

 

 

 

 

 


© 2017 by Stephen Wong