This discussion is archived
10 Replies Latest reply: Oct 9, 2011 9:45 PM by EJP RSS

Registry workings?

800330 Explorer
Currently Being Moderated
Hi,

The inherited RMI server application has the following way of hosting multiple instances on the same host machine, and I wonder whether my alternative approach would be better.

Currently the server app is started with a port number. The port number goes into the LocateRegistry.getRegistry() call and the exported service object is registered under the a fixed name with that registry. Starting two of these one at 1099 and one at 1199, results in two servers that clients can reach at ports 1099 and 1199 using the same fixed name.

The alternative I was thinking of (and seems more in line with what I have learned browsing the RMI docs, related to my other recent thread) is starting the server app with some identifier, A and B. On startup the registry is located at a fixed port (1099) and the name includes the identifier. Now clients can reach each of the servers by using the fixed port and differing the name, A or B.

Are these approaches equivalent?

Suppose A is started first, then B. Is B still reachable if the JVM running A is exited (System.exit(0))? Currently, we can remotely stop a server by calling stop() over RMI which exits the JVM like that. I fear it will kill the registry too and I'll need to implement the stopping differnently too.
  • 1. Re: Registry workings?
    EJP Guru
    Currently Being Moderated
    You don't need two Registries. If a Registry is exported from a JVM that subsequently exits of course it will stop. If the Registry is a separate process from A and B and one of A and B exits then other will still be reachable, unless A and B were in the same JVM.
  • 2. Re: Registry workings?
    800330 Explorer
    Currently Being Moderated
    Do I have any influence on the process that runs the registry? Currently, the server app main-method does
                   reg = LocateRegistry.getRegistry(port);
    I am thinking this starts the registry in that JVM-process if none was running before. If so I see the solution being to run a registry hosting process, separate from my multiple server apps. This is not unfeasible, but complicates the setup a bit...
  • 3. Re: Registry workings?
    EJP Guru
    Currently Being Moderated
    I would investigate running the Registry, A, and B all in the same JVM. One failure mode, simpler setup, better all round.
  • 4. Re: Registry workings?
    800330 Explorer
    Currently Being Moderated
    I think I cannot bring them all under one JVM under our current operations. We have server app version 3.4 running now at port 1099. By the time we think we're done with v3.5 we host that on port 1199, hook up the functional testing client app to 1199 and when "they" are satisfied we switch the ops client to 1199 and after a week (in case we need to roll back) exit the server app at 1099. We tend to host yet another server app on port 1299 which is an older version (v3.1) but which is functionally different due to configuration settings (for clients of a different type) which we keep on for a year or so before "upping" to the current version.

    I could think of adapting the server app in order to bring them all under one (or less than a jvm per instance) but I do not see compelling reasons yet to go about all that yet...
  • 5. Re: Registry workings?
    800330 Explorer
    Currently Being Moderated
    I am thinking this starts the registry in that JVM-process if none was running before.
    Which is not true, a bit further down in the code a registry is created explictly in case none was found.
  • 6. Re: Registry workings?
    EJP Guru
    Currently Being Moderated
    I am thinking this starts the registry in that JVM-process if none was running before.
    All that LocateRegistry.getRegistry() does is construct a RegistryStub according to the parameters you provide. It doesn't even perform any network operations. If the parameters you provided are incorrect you won't find out until you try to use it. So if you are trying to create a Registry if not found, you have to try the createRegistry() first, and if that fails, do the getRegistry(). Not the other way around.
  • 7. Re: Registry workings?
    800330 Explorer
    Currently Being Moderated
    Well, the code in my project is by exception: it gets the stub, then tries to lists it's services and failing to do so leads to the construction of a fresh Registry on that port. Similar in effect,no need to go change that just because I don't like that style...
  • 8. Re: Registry workings?
    EJP Guru
    Currently Being Moderated
    Similar in effect but it requires a network operation, whereas trying to create the registry first only involves local operations. And that is still 'by exception'. And 'style' really has nothing to do with it.
  • 9. Re: Registry workings?
    800330 Explorer
    Currently Being Moderated
    I don't see that. I'd naively consider the getRegistry(port) lookup equivalent to createRegistry fail while some other VM is hosting one on the localhost, requiring the same "network probing".

    With the code base I am working on, there are so many things I'd do differently if I were to write it from scratch but I rather leave them untouched and spend my time on the parts that are just as ugly/awkward/clumsy/pre-generics but known to be broken. I was thinking in my OP to be able to save some trouble by sharing the Registry among instances, but the complications in stopping one instance made me reconsider. My feeling now is to leave this part alone for now. Being a lot the wiser on RMI and ready for a future issue, thanks to you.
  • 10. Re: Registry workings?
    EJP Guru
    Currently Being Moderated
    I'd naively consider the getRegistry(port) lookup equivalent to createRegistry fail while some other VM is hosting one on the localhost, requiring the same "network probing".
    Reviving this ancient thread to note that getRegsitry(port) isn't a lookup, and doesn't do anything to the network, as had already been stated above, so the entire argument falls over.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points