Home > Blockchain >  java rmi - how to handle RemoteException
java rmi - how to handle RemoteException

Time:10-14

I have checked some of the Java RMI examples. But none of them demonstrate how to recover from a potential server failure, or a RemoteException, which might be thrown from the remote interface we define. And I couldn't find any relevant information either.

For instance,

public static void main(String[] args)
{
    try
    {
        Server server = new Server();
        Hello stub = (Hello) UnicastRemoteObject.exportObject(server, 0);
        Naming.rebind("rmi://localhost/Hello", stub);
        System.out.println("Server is up.");
    }
    catch (RemoteException e)
    {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
    catch (MalformedURLException e)
    {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

After the exception is caught, the server just exits. Is here the intent for the server to die when such exceptions are thrown? Can we recover from such failures, like restarting the server? But how?

Thank you,

-----------Updates----------

To clarify, initially, I thought the RemoteException specified in the remote interface might be caught here. But after some experiments, I find they will actually show up on the client side and should be handled by the client.

CodePudding user response:

Your RMI server only throws that exception at initialisation / start-up in UnicastRemoteObject.exportObject or Naming.rebind. The chances are that any error here isn't recoverable simply by running a loop to perform the same action again. There is some other problem to investigate.

If you server gets past the exportObject/rebind you see the "Server is up" message, the execution passes through the catch block and main(String[] args) ends normally. Even the thread handling [main] probably ends here.

But, the JVM process does not exit as there are non-daemon threads running. Any exceptions in the server are not passed back to the catch(RemoteException e) block shown in your main because main() has ended already.

In live systems I've observed several measures used by developers to counter issues found with RMI servers:

  • server startup scripts use limited loop to retry startup if it dies (this is more effective if it dies after long period not if fails instantly)
  • periodic round trip rmi client to server calls with trivial operation to prove RMI server health
  • run multiple instances of rmi servers with deliberate shutdown restart cycles at different time to ensure 100% operation
  • process monitors on rmi servers => trigger alerts for manual intervention

Most importantly you need effective logging so you can diagnose why it died afterwards.

  • Related