Simple entry point for single RMI service?

Question

I have several services which export an RMI interface.

They used to offer this by creating their own registry (with LocateRegistry.createRegistry) and binding it there. However, that became impossible when the services were moved to run as separate applications in the same VM (Tomcat), because for some reason only one registry can be present there.

I worked around this by using a central registry for all the services. Even then, I'm not really interested in the multi-object registry role of a registry, just its entry point facilities. A central registry, however, introduces more complexity (e.g. it must be started first, it must have the interfaces of services it registers).

Is there a way to bring back the situation where each service indepently offers an entry point to its RMI interface, while having them run in the same VM (which is a hosting detail, not part of the design)?

Aquilegia

Answer 1

I'd forgotten that I asked a similar question already (for a different reason, reducing code, before I moved services together in 1 VM), where the first answer suggests a way to circumvent the registry:

Use UnicastRemoteObject, serialize the stub obtained when you export the object, and use a shared file, or a socket, or sneakernet, to make the stub available to clients.

Aquilegia

Answer 2

You can't have more than one Registry per JVM, because the Registry has a fixed RMI object ID. Just adjust all your servers to start like this:

static Registry registry;
// ...
try
{
  registry = LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
}
catch (...) // whatever the exception is, probably ExportException
{
  registry = LocateRegistry.locateRegistry(Registry.REGISTRY_PORT);
}
registry.rebind(...); // etc

Then whichever one of them starts first will start the Registry and the others will use it.

Houlberg

I did that, for a while, but that's even more complex and error prone. The whole architecture then depends on whichever service happens to start first. If it stops/restarts, all the other ones need to rebind there, and are unavailable while service 1 restarts. Also, it brings a hosting detail (one VM) into the code. – Aquilegia

@BartvanHeukelom No it doesn't. It doesn't matter which RMI server starts first. If they all do as above, the one that starts first will create the registry and the others will locate it. I'm not aware what 'hosting detail' is being brought into play when a hostname isn't even mentioned. – Houlberg

Indeed, it doesn't matter which starts first, but whatever service it is, the whole system then depends on it, and it can't be stopped or restarted. By hosting detail I mean that the fact that the applications share a VM is a matter of hosting/server setup, not relevant to their design. – Aquilegia

@BartvanHeukelom So now you are back with running it as a separate process. You can't have it both ways. – Houlberg

Well, I can, by using option 3 from your answer to the other question. But I'm wondering whether the client can maybe synthesize the entire remote stub, which would be even easier. – Aquilegia

@BartvanHeukelom Well that's yet another question. The answer is 'yes', because locateRegistry() does exactly that, but you have to export the object with a fixed objectID, which is non-trivial, uses Sun APIs, etc. Have a look at locateRegistry() and the source code of RegistryImpl if you want to follow that path. – Houlberg

Answer 3

If you're still interested in this problem a year later....

It is possible to start multiple registries within the same JVM. Just call LocateRegistry.getRegistry with distinct ports. You have to have well-known ports for each service, but I think you're doing that already if you've implemented option 3 from this answer to the other question.

Long ago there was a bug that prevented multiple registries from coexisting in the same JVM, but this was fixed in JDK 5. There may be something in Tomcat that prevents multiple RMI registries from running. Or, it could be that the version of Tomcat you were using was on top of a very old JDK.

Hemisphere