All the answers so far are incorrect. The Registry normally uses port 1099, but you can change it. But that's not the end of the story. Remote objects also use ports, and not necessarily 1099.
If you don't specify a port when exporting, RMI uses a random port. The solution is therefore to specify a port number when exporting. And this is a port that needs opening in the firewall, if any.
In the case where your remote object extends UnicastRemoteObject
, have its constructor call super(port)
with some non-zero port number.
In the case where it doesn't extend UnicastRemoteObject
, provide a non-zero port number to UnicastRemoteObject.exportObject()
.
There are several wrinkles to this.
If you aren't using socket factories, and you provide a non-zero port number when exporting your first remote object, RMI will automatically share that port with subsequently exported remote objects without specified port numbers, or specifying zero. That first remote object includes a Registry created with LocateRegistry.createRegistry().
So if you create a Registry
on port 1099, all other objects exported from that JVM can share port 1099.
If you are using socket factories, your RMIServerSocketFactory
must have a sensible implementation of equals()
for port sharing to work, i.e. one that doesn't just rely on object identity via ==
or Object.equals()
.
If either you don't provide a server socket factory, or you do provide one with a sensible equals()
method, but not both, you can use the same non-zero explicit port number for all remote objects, e.g. createRegistry(1099)
followed by any number of super(1099)
or exportObject(..., 1099)
calls.