Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Can multiple servers share one RMI Registry?

 
Jason Farhein
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'm new to RMI, and I have this question: Can multiple servers share one RMI Registry? Let me give you a context:

I have client A and server B and a class O. Client A would like to execute an instance of O remotely on server B. (Client A has access to an interface for O, of course).
Therefore, server B created an RMI registry and binds address "//B:1009/O" to its instance of O so A can look it up and remotely use it.

Now, a person has told me that if there are multiple servers, there's no need to create more RMI registries. That is, if client A wants to execute another instance of O, which is on server C, then C does not have to create its own RMI registry. Instead, it can use B's RMI registry, and simply bind address "//B:1009/C" to its instance of O.

Does this make sense to you? Wouldn't it be straight forward for C to have its own RMI registry? Thanks for your insight!
 
Jason Farhein
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, I just did a simple test, and it looks like you cannot create a binding with a non-local address.
Example,

the following code is executed on server B and it starts up RMI service just fine.




the following code if executed on server C (note it tries to use server B's address to bind its own Hello instance)


Will throw the following E:
java.rmi.AccessException: Registry.Registry.rebind disallowed; origin /<C's address> is non-local host


Is this expected (C cannot borrow B's RMI registry) or am I just doing it wrong somehow? Thanks!
 
Chris Janicki
Greenhorn
Posts: 22
Mac OS X Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know that multiple JVMs can share the same Registry on a server. The Registry is basically a hash map of arbitrary (but hopefully unique) object names to the TCP/IP socket server address of each instantiated Remote object. The Registry is sort of like DNS.

I don't see any technical reason why your cross-server idea shouldn't work. However, there are lots of security reasons why a multi-server Registry might be a bad idea. For example, I don't think the Remote object's name space is protected at all, so you might have a rogue process on another machine overwrite (rebind) over the top of your Remote object, causing some headaches. I'm a little surprised that Sun allowed multiple JVMs to share the Registry, for the same reason, but they did.

So, bottom line, it's probably not going to work.

If it's important, you could write your own Registry replacement… just a hashmap of String names pointing to the Remote objects that registry with it. Your more liberal version of the registry could implement a getRemote(String name) method that returns Remote, and a bindRemote(String name, Remote remote) method that would accept calls from any server (using an RMI Registry on your main "lookup/directory" server.).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic