Using single RMI Registry

Question

Hi

I've been using RMI for a project I am currently working on and I want to bind from multiple hosts to a single RMI registry.

However when I attempt to do so I get an error saying

java.rmi.AccessException: Registry.Registry.bind disallowed; origin / 192.168.0.9 is non-local host

I did so googling and it seems that RMI stops remote hosts from binding by default, what I want to know is there some way of overriding or bypassing this?

If anyone any suggestions on how to get past this issue they would be highly appreciated, i've tried using different policy files and overriding the security manger but none seem to work.

Answer 1

I may be wrong, but it looks like rmiregistry application is essentially a wrapper over local naming service. Which means there is no way to make it point to remote objects.

What you need is a Naming implementation, and clustered at this. Consider to move into J2EE AS clustering solution. JNDI tree is shared within the cluster.

Answer 2

I may be misunderstanding your question, if so please let me know.

I have limited experience with Java RMI, we used it in our Design Patterns class with the Proxy Pattern. (Textbook: Headfirst Design Patterns)

We were not able to get our projects working from outside the university network, but they worked perfectly when connected directly to the network. According to our professor, it wasn't possible to use RMI in our implementation over the internet or wan. A solution she suggested was that a VPN would be required. I believe Vladimir is correct in that it has to do with it being a local naming service.

Answer 3

There's a way to get around the limitation but it is what it is: a work-around. Anyway, feel free to try it out. It works for us.

On the host that is running the central RMI registry run a small service which will bind a remote object with just one remote method: proxyRebind. The implementation of this method simply binds the object that is supplied to it in the central registry (this would not fail because the registry is on the same machine as this service).

All other hosts would simply lookup this remote object and invoke proxyRebind with their own remote objects.

This works because look-up on remotely hosted registries is allowed. Your original attempt failed because binding on remotely hosted registries is not allowed.

Let me know if you need any further clarity on this.

/RS

Answer 4

Thanks for everyones answers the solution I came up with in the end was to use the Cajo Framework this gives a very flexible system for distribution and it allowed for me to handle the registry as I saw fit. It can also work behind NATs, firewalls, and HTTP proxies, which is very useful.

I believe that the method of proxying suggested by rndm.buoy will work in some cases but its may be troublesome on some system. RMI seems to have some issues with associating to the wrong Network Interface I particularly had this issue when running on Debian based Linux distributions.

Answer 5

2 There's a way to get around the limitation but it is what it is: a work-around. Anyway, feel free to try it out. It works for us.

On the host that is running the central RMI registry run a small service which will bind a remote object with just one remote method: proxyRebind. The implementation of this method simply binds the object that is supplied to it in the central registry (this would not fail because the registry is on the same machine as this service).

All other hosts would simply lookup this remote object and invoke proxyRebind with their own remote objects.

This works because look-up on remotely hosted registries is allowed. Your original attempt failed because binding on remotely hosted registries is not allowed.

Let me know if you need any further clarity on this.

This perfectly works. The only thing to take care is following should be always set correctly. -Djava.rmi.server.hostname="LOCAL HOST IP"