java.rmi.NoSuchObjectException?
When I make an invocation on the server, I get java.rmi.NoSuchObjectException?
What is the problem?
Overview of RMI
When you export a RemoteObject via RMI, the RMI server keeps a map of "object id" to the server side skeleton that is used to locate and invoke upon the exported object.
These mappings (object ids) only last for the duration of the JVM.
If you reboot, you don't get the same object id.
If you export on a different server you get a different object id.
If you rebind, you get a different object id.
The remote stub given to the client holds this object id. It also holds the ip address or host name of the server.
Problems
You rebooted the server
If you reboot the server, any remote stub held by clients are now invalid.
You contacted the wrong server
You have some bad dns/bind configuration that means the remote stub holds the wrong ip address or
host name.
The remote object is no longer bound on the server
You undeployed the remote object (if it was explicitly bound).
If it was implicitly bound, e.g. passed as a parameter on an RMI request, the distributed GC has decided that nobody is using it - nothing in JBoss uses implicit binding
Your DNS' localhost is set to loopback, 127.0.0.1
Alter /etc/hosts to have the localhost entry match the IP address of your machine. Also some Linux distros (e.g. Ubuntu) add an entry matching the hostname to 127.0.1.1. This entry will need to be changed to the IP address of your machine, too.
Solutions
Traditional RMI
If you use traditional RMI, the only solution is to reget the remote stub from the server.
e.g. for JBoss's Naming that uses RMI by default, recreate the initial context.
HARMI
If you use JBoss's HAJNDI or JBoss's JRMPInvokerHA, these use JBoss's HARMI.
This will transparently find a different server to make the request and re-retrieve the remote stub for the rebooted server when it changes.
However, this won't help if you reboot the entire cluster. Then all the remote stubs held by the client are invalid. Revert to the traditional RMI solution.
Other transport
Don't use RMI. Use a protocol more tolerant of server reboots, e.g. the pooled invoker or http invoker.
Related
Referenced by:
Comments