COMP 310 Fall 2011	Lec39: RMI Garbage-Collecting and Final Project Quests

See Nov. 22 Lab notes in Owlspace wiki

API Questions

How can multiple remotely loaded ADataPacketAlgoCmd's communicate with each other?

• High security implementation: They can't.  They can only communicate back to the game server.
• Low security implementation:   Give the commands access to some services, e.g.
  • The main visitor
  • The team chat room
  • A common MapPanel
• Medium security implementation:   ICmd2ModelAdapter provides only select methods for
  •    Selected operations on the some of the above entities.
  • Access to a common "Mixed Data Dictionary" to store shared objects or that can provide inter-command communications.

Should the game client provide a MapPanel for a ADataPacketAlgoCmd  to use?

• Pro:  Releases the game commands from having to manage it.
• Con:  More restrictive.

Game Questions

• What is a quest/puzzle?
• What constitutes a “clue”?
• How do you want players to interact with the map?
• How do you want to keep score, if there is such a notion during the game?

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:

• Maintain a reference to the Remote object by saving it in a field somewhere.
• For multiple, unknown numbers of Remote objects, try throwing them into a storage container of some sort such as a Vector.

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.

© 2011 by Stephen Wong and Scott Rixner