Version 8



    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.




    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,


    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  This entry will need to be changed to the IP address of your machine, too.




    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.




    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.





    Referenced by: