COMP 310
Fall 2010

Lec39: RMI Garbage-Collecting and Final Project Quests

Home  Info  Owlspace  Resources

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.



Final Project Quests/Puzzles

 We have a very generalized notion of what a "clue" is, but we still need to iron out the overall notion of what a "quest" or overall game-level "puzzle" is.   We will work in small groups today to brainstrom and hopefully make some progress on this.






© 2010 by Stephen Wong and Scott Rixner