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, ...