Java RMI connection broken

Question

We have an java client-server RMI application. The client performs a call by:

public interface MyRemoteInterface extends java.rmi.Remote {
    public byte[] action(byte[] b}

public static Remote lookUp(String ip, int port, String alias) {
    return LocateRegistry.getRegistry(ip, port).lookup(alias)
}


 serverImpl = (MyRemoteInterface)lookUp(ip, rmpiport, alias);

 serverImpl.action(requestBytes);
 ..

It a classic rmi client-server appl. When the remote server receives the request (call) it performs some process P, which takes a time T and then returns. The problem is, suppose we have two clients C1 and C2, respectively, each are identical (same OS, same Java, no firewall, no antivirus etc). The difference of C1 and C2 is they are in different networks, different ISP provides etc. For example they are two users connecting from their home and use different service providers, modems and connecting to the centralized server S. When the process P takes 4 minutes, there is no problem, both client receive the response. But if the process time takes for example 10 minutes, C2 receives no response without any exceptions on server or client side. Question: What can be reason of this difference? How can the network architecture can effect the behaviour of rmi connection? Can we overcome this problem by setting some timeout parameters or jvm-parameters? We do not get any timeout exceptions on client or server. Simply one of the clients does not receive any response if the process time becomes longer.

Answer 1

Simply one of the clients does not receive any response if the process time becomes longer.

In our (enterprise) network we had some policy in force to close connections which were not active for long time. So there may be differences. Though the client should get a proper exception. For better answer you may gather more exact information on the network level (eg tcpdump)

But if the process time takes for example 10 minutes

I'm not really fond of long-running processes when executing remotely (regardless of the protocol). Mainly to prevent issues like the one in your question.

You may use some asynchronous processing, like a method to start a server process and then have the client to check for status/results.