RMI Naming.lookup exception, what is it?

[Shin]

I got the following RemoteException when executing a lookup statement,
how to decipher this:

java.rmi.UnmarshalException: Error unmarshaling return header; nested
exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:203)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:84)


Thanks,
-Shin

 

[segex]

Have you checked all the possibilities, which are written in the API?:

# if an exception occurs while unmarshalling the call header
# if the protocol for the return value is invalid
# if a java.io.IOException occurs unmarshalling parameters (on the
server side) or the return value (on the client side).
# if a java.lang.ClassNotFoundException occurs during unmarshalling
parameters or return values
# if no skeleton can be loaded on the server-side; note that skeletons
are required in the 1.1 stub protocol, but not in the 1.2 stub
protocol.
# if the method hash is invalid (i.e., missing method).
# if there is a failure to create a remote reference object for a
remote object's stub when it is unmarshalled.

 

[Shin]

Thanks. Mmh, sometimes you need someone to point that to your face to
ring a bell. In this case, the following is the reason.

# if no skeleton can be loaded on the server-side; note that skeletons
are required in the 1.1 stub protocol, but not in the 1.2 stub
protocol.

I don't know why the default rmiregistry to run on my machine is set
to: /usr/i686-pc-linux-gnu/gcc-bin/3.3.5/rmiregistry, which is
different than the rmic and java directory used.

Should these rmiregistry smart enough to try either of these protocols,
or the gnu version is too old?

-Shin

 

[E.J. Pitt]

I don't know why the default rmiregistry to run on my machine is set
to: /usr/i686-pc-linux-gnu/gcc-bin/3.3.5/rmiregistry, which is
different than the rmic and java directory used.

Should these rmiregistry smart enough to try either of these protocols,
or the gnu version is too old?

In my experience the GNU version should simply be deleted whenever &
wherever encountered. It does not appear to interoperate with the JDK.