I am writing a very simple RMI server, and I am seeing intermittent java.rmi.NoSuchObjectExceptions
in the unit tests.
I have a string of remote method
there is one point missing in the above discussion. There is something that is called distributed garbage collection (DGC). If there are no living local and remote references to a distributed object the GC is allowed to remove the object from memory. There is a sophisticated algorithm to verify this. The nice code snippet from above is indeed a good demonstration of the effectiveness of the DGC.
What somehow looks like a feature is nothing but the designed behavior!
Frank
Got the same error but probably for the other (yet unknown) reason.
I was casting exported object to the type of my remote interface and then while binding to name I was getting NoSuchObjectException. Removing casting fixed the problem.
Briefly:
public interface MyRemoteInterface extedns Remote {
...
}
public class MyRemoteObject implements MyRemoteInterface {
...
}
public static MyRemoteObject obj = new MyRemoteObject();
public static void main(String[] args) {
//removing cast to MyRemoteInterface fixes the problem
this.obj = UnicastRemoteObject.exportObject((MyRemoteInterface) this.obj, 0);
//unless the above cast is removed, this throws NoSuchObjectException occasionally
LocateRegisry.getRegistry("127.0.0.1", 1099).bind("name", this.obj);
}
It's difficult to answer this question without looking at the code (which I guess will be big enough to not be publishable here). However, using Occam's razor, you have two possibilies
I would suggest you go over the code paths carefully keeping the two points above in mind.
While using spring remoting (rmi) i bumped into this error. My service wasn't garbage collected.
After turning on debug logging for "org.springframework" i discovered that my server was registering the service on the default port (1099) instead of the port the client was trying to connect to.
I thought everything port wise was ok cause "java.rmi.server.logCalls=true" did show some output on server when client was trying to connect.
When getting this error double check the ports (the service and registry one).
Some other questions to consider - First are you referencing an object instance or is the stub interface itself gone? If some object instance is gone, its for the usual reasons, it got dereferenced and GC'd, but if it's the interface then your RMI server end point loop quit for some reason.
The best debugging tool I've found so far is to turn on the java.rmi.server.logCalls=true property (see http://java.sun.com/j2se/1.5.0/docs/guide/rmi/javarmiproperties.html) and watch all the wonderfull information stream down your log window. This tells me what's up every time.
jos
I have the same problem and now I've solved it. The solution is simple, you MUST create strong reference 'object' to avoid the object being GC'd.
for example in your server class:
...
private static ServiceImpl serviceImpl = null;
public static void register (int port) {
serviceImpl = new ServiceImpl();
Registry registry = LocateRegistry.createRegistry(port);
registry.rebind ("serviceImpl", serviceImpl);
}
public static void main(String[] args) throws RemoteException, NotBoundException {
register(1099);
...the rest of your code...
}
So, it protects "serviceImpl" object from being GC'd. CMIIW