Using single RMI Registry

Question

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.

Presentment

Answer 1

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.

Presentment

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

/RS

Nicholnichola

That's clever! Sounds like something that might be closed up as a potential security hole in a future release of the JRE. I wouldn't make any major design decisions depend on this technique. – Cogency

If it were to be closed up, would have happened a long time ago! I have been doing this implementation for the past 10 years! – Nicholnichola

rndm.buoy I've attempted to implement this and the object does indeed bind succesfuly however when I attempt to invoke a remote method I get the exception java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is: even though the remote object should resolve to the IP 192.168.126.137 I'm wondering if there is something i'm missing could you please expand on your suggestion it would be greately appreciated. – Presentment

Answer 3

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"

Translucid

It is only necessary to set java.rmi.server.hostname in a multihomed host or if there is something wrong with your DNS as described in item A.1 of the RMI FAQ. – Subclavian

Answer 4

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.

Slapstick

No. It has to do with callbacks being infeasible over networks with client-side proxies, and the issue described in item A.1 of the RMI FAQ. 'Local naming service' is a figment of the imagination. – Subclavian

Answer 5

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.

Slacks

You are wrong. The RMI Registry is a naming service. It isn't a wrapper over anything. It just won't accept bind/rebind/unbind requests other than from the localhost. That isn't the same thing as not being able to point to remote objects. It can. – Subclavian