The moose likes Distributed Java and the fly likes RMI - load balancing - NoSuchObjectInTable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "RMI - load balancing - NoSuchObjectInTable" Watch "RMI - load balancing - NoSuchObjectInTable" New topic

RMI - load balancing - NoSuchObjectInTable

Tepih Taskuhwilly

Joined: May 28, 2009
Posts: 6
Hi all,

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?
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230

Do you need to have multiple RMI registries? Can you have the servers share an RMI registry?

Ajay Saxena
Ranch Hand

Joined: Nov 13, 2006
Posts: 154
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.
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
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.

Hope this helps,
I agree. Here's the link:
subject: RMI - load balancing - NoSuchObjectInTable
It's not a secret anymore!