如何在某个自由端口上创建一个新的、唯一的 RMI 注册表？

Question

Situation

I'm writing a Jenkins build step plugin, and want my other processes on localhost to call my plugin's main process' functions and give it data objects.

For this, I decided to use RMI, therefore I want to create an RMI registry, so the other processes can call my functions:

https://docs.oracle.com/javase/7/docs/api/java/rmi/registry/LocateRegistry.html

I want the registry to take any free port available on the system. Usually this is done by providing a port of 0 to the registry/socket creation.

However, an RMI registry maintains an ID, preventing a subsequent creation if a registry of that ID already exists on the JVM. With a port of 0, that registry's ID is 0.

Question

There are other actors on the same JVM instance (plugins), that may have created or may want to create a RMI registry on port 0 for port discovery. This prevents me from creating my own registry with a free port. This is my problem, because I don't want to collide with other registries on this JVM, yet still get an available free port.

Is there some solution for this?

Did I get something wrong?

Things I rejected

• If I used an existing registry, I'd be concerned that my bindings will collide with existing bindings.

• I tried to provide a custom RMIServerSocketFactory implementation to LocateRegistry.createRegistry , choosing a free port (port = 0), and calling createRegistry itself with any other port for id. However, the created Registry somehow uses the correct port, but internally thinks it uses the given port. I am concerned, this will lead to further problems later on. Also, I cannot reliable choose a nonexisting id, as I'd have to try several if they turn out to be used already. This is the same problem I set out to solve with the ports.

• Poking a port with a socket connection, then creating a Registry on that port does not work for me. Because this introduces a gap between forfeiting the port and creating the registry on that port. And I don't want another process to jump in and take the port in the mean time.

Answer 1

Summarizing what I found out in the mean time, RMI is not a good fit for the scenario I want to cover.

Java's RMI mechanism is designed for:

• sharing a Registry at the default port of 1099
• sharing a Registry at a specific port that you provide beforehand

In both cases these problems apply:

• If the port is already in use then creating the Registry fails, leaving open what to do about it.
• Reusing an RMI registry that you do not control yourself brings about the possibility that the registry goes down mid-communication (because its process can go down for any valid reason).
• "Look if the default Registry exists, if not create it" is a bad pattern, if your process is short-lived. Other processes will bind to your created Registry, which then goes down with the process.
• All server instances on the same Registry need to use a binding that hopefully does not collide.
• If there are several similar server/client processes that use the same implementation (for example parallel jobs), and therefore the same binding names, they need to sort out their individual communication through unique binding names.

The RMI mechanism is not designed for creating an ad-hoc RMI registry that is dedicated to a single server/client communication:

• Creating an RMI registry on a random free port (by providing port=0) works only on the very first call within this JVM process. Any further attempts at creating another RMI registry on another random free port fails.
• Creating an RMI registry on a random free port (by custom RMISocketFactory) leads to inconsistent internal state. Also, you need to sort out which ID to give the Registry up front, which defeats the purpose of using an RMI registry in the first place.
• An RMI registry cannot be closed. It stays online as long as the process's JVM stays.

Therefore, in a plugin scenario, where, within the same JVM, other actors may execute code, and you need to start several communications to very similar spawned processes, and there may be other processes around, that do the same thing, RMI opens several points of failure that cannot easily be mitigated.