Java Enterprise Best Practices

Include Logic for Retrying Remote Calls

Everyone knows that networks fail. Failures can range from small-scale and transient to massive and persistent. Obviously, in the case of massive and persistent network failures, a distributed application will not work. But your application can be built to survive small-scale and transient network failures.

One of the best things you can do to make your application more robust is implement a retry strategy. That is, whenever you make a remote call, wrap it in a loop based on catching RemoteException , as in the following code snippet:

public void wrapRemoteCallInRetryLoop( ) {
	int numberOfTries = 0;
	while (numberOfTries < MAXIMUM_NUMBER_OF_TRIES) {
		numberOfTries++;
		try {
			doActualWork(  );
			break;
		}
		catch (RemoteException exceptionThrownByRMIInfrastructure) {
			reportRemoteException(exceptionThrownByRMIInfrastructure);
			try {
				Thread.sleep(REMOTE_CALL_RETRY_DELAY);
			}
			catch (InterruptedException ignored) {}
		}
	}
}

This method is simply an encapsulation of a loop. It relies on two other methods, doActualWork( ) and reportRemoteException( ) , to make the remote method call and to report failures in communicating with the remote server, respectively. This code also assumes that RemoteException indicates a network failure, and that retrying the method call a small (and fixed) number of times is a reasonable strategy when the RMI infrastructure throws an instance of RemoteException.

Note that in some cases this is not the correct behavior. For example, ...