I have two machines behind TCP load balancer. Each machine hosts RMI registry on port A, and remote object server on port B. Client sees hostname rmi and ports A and B. When trying to connect, the hostname will be resolved to load balancer and load balancer will route request to one of the machines.
The problem is that first client goes to RMI registry. Load balancer will direct it to random machine and client will obtain stub from that machine. The next step is that client will try to call
server object using the stub provided in previous call. However, the load balancer will route it to another machine where the stub has different remote object Id and the call will fail with NoSuchObjectInTable exception.
So one solution will be to make stickiness on load balancer to route both ports A and B to same machine in case of same source IP address.
But can this be solved on RMI server side somehow so that the both stubs would display same remote object ID?
Joined: Apr 07, 2007
Do you need to have multiple RMI registries? Can you have the servers share an RMI registry?
Joined: Nov 13, 2006
Can't we restrict the Load balancing to just obtain the stub ,and then invoke the remote service on the stub directly,bypassing the Load balancer? Of course it would reduce the usefulness of the load balancer in terms of distributing the RMI invocations.
Joined: Apr 07, 2007
A couple of other points to keep in mind. If you have so many connections that you need a load balancer, RMI may not be the best of choices. Underneath, RMI uses sockets and opens a new connection for each concurrent connection. So if you have so many concurrent requests that you need to load balance, you may have issues with opening too many sockets.
By using a shared registry, you can eliminate the problem of having no such object in the table. But, to improve scalability, you can do some stub caching. For example,
The request is routed to machine A and checks its cache and sees it does not have the stub. It then, and only then, goes to the registry to look it up. Next request to machine A won't require a trip to the registry since the stub will be cached.
You can then apply the same approach to machine B, C, etc. Even though they are sharing a registry, the caching should reduce the number of calls to it.