Problems with RMI

Lindeijer, D.G. D.G.lindeijer at WBMT.TUDELFT.NL
Mon Jul 17 04:47:32 PDT 2000


Hello,

Thanks Archie for the possible fix for the incorrect URLs, I'll try to
implement the fix when I get round to it, till then I will use my workaround
which is simply putting the requested class files in the codebase with their
names prefixed with their package names. 

Another problem I have encountered can not be solved with the workaround.  I
created a server a.b.c.AgvRegistryImplBase which I bind in the (local)
rmiregistry under the name "agvRegistry". 

////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////

public class AgvRegistryImplBase 
    extends java.rmi.server.UnicastRemoteObject
      implements AgvRegistry {

  AGV agv;

  public void rebind(String name,AGV agv) {  // remote method
    this.agv = agv;
    System.out.println("AgvRegistryImplBase.rebind agv with name=" + name +
" =" + agv.toString());
  }

  public AGV lookup(String name) {  // remote method
    System.out.println("AgvRegistryImplBase.lookup agv with name=" + name);
    return agv;
  }

} 

////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////

A client-program on another linux-machine (running on a kaffe JVM) finds the
(sun) rmiregistry and successfully executes a lookup for "agvRegistry" which
results in an (erroneous) download request for "http : // hostname /
codebase / a.b.c.AgvRegistryImplBase_Stub".  (The download is successfull
thanks to the rename workaround I mentioned above.) 

////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////

public class MiniAgv extends MachineImplBase implements
com.agileways.forces.machine.agv.AGV {

  public static void main(String args[])
  {
    String name = "vehicle_101";
    MiniAgv miniAgv = null;
    try {
      miniAgv = new MiniAgv(name);
      System.out.println("Started miniAgv: "+ miniAgv.getName());
      if (true) {
 
System.out.println("Naming.lookup(//dutw1700.wbmt.tudelft.nl/agvRegistry)");
        AgvRegistry agvRegistry =
(AgvRegistry)Naming.lookup("//dutw1700.wbmt.tudelft.nl/agvRegistry");
        System.out.println("found agvRegistry=" + agvRegistry.toString());
        agvRegistry.rebind(name,miniAgv);
        System.out.println("Rebound miniAgv: "+ miniAgv.getName());
        agvRegistry.lookup(name);
        System.out.println("lookup miniAgv myself apparently worked");
      }
    }
    catch (Exception e)
    {
      System.out.println("Exception in main: " + e.getMessage());
      e.printStackTrace();
    }
  }
}

////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////

The AgvRegistryImplBase_Stub is reserialized correctly because I can make a
remote call "agvRegistryRemote.rebind(String,AGV)" on it which indeed
arrives at the remote server. I know this is true because the server
executes the println statement which I inserted into its remote method
"rebind(String,AGV)", the println statement is the very last statement of
the method. The problem is that at the client side the method-call does not
return. It turns out that the RMIClassLoader is (reptitively) trying to
download from the codebase "[Ljava.rmi.server.ObjID;.class" which I believe
is the class-definition of an array of "java.rmi.server.ObjID.class". This
is strange because "java.rmi.server.ObjID.class" can be found in kaffes
rmi.jar . 

The client hangs because the remote call does not return. If I kill the
AgvRegistryImplBase server then the client breaks with a "connection reset
by peer" exception. 

Its not clear to me if the "[Ljava.rmi.server.ObjID;.class" download request
start before the remote call to AgvRegistryImplBase or upon the return of
the call. 

Does anybody have suggestions how to tackle this problem? If I run client
MiniAgv on the linux-machine with the blackdown JVM it all works fine, but I
unfortunately that JVM has too large a footprint.  


Thanks

David Lindeijer.



More information about the kaffe mailing list