• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Can multiple servers share one RMI Registry?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Greenhorn
Posts: 25
Mac OS X Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.).
 
Why should I lose weight? They make bigger overalls. And they sure don't make overalls for tiny ads:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic