RMID, RMIRegistry and ports

[James Cook]

An interesting one for you all.
The Java Activation Tutorial mentions starting RMID (using default port 1098) followed by starting the RMIRegistry (on default port 1099) and then registering the Activatable object in the normal manner with the Activator in RMID and the object with the RMIRegistry. This is because the Naming.rebind() call uses the default port for binding to the Registry (port 1099) and that is where the RMIRegistry is sitting, listening for Registry calls.
Now RMID has its own registry, so if you (a) call Registry.locateRegistry(1098), you will talk to the RMI Registry in RMID - even if the RMIRegistry is busy running at the same time on port 1099.
So, if you bind an Activatable object with the RMIRegistry on port 1099, how does RMID get informed to activate the object?
Surely the only way to Register an Activatable is by using RMID's registry on port 1098?
If you specify a different port to RMID with
-port nnnn, then, again, I think you would Registry.locateRegistry(nnnn) for the Naming.rebind(), and then talk to the RMID registry on this new port.
If this is the case, what on earth is the point in starting up a completely separate RMIRegistry (on port 1099)? Surely it's just ignored.
If it is ignored, why does the tutorial ask that you start up RMIRegistry after starting up RMID..
!$%^!
Must be something I'm missing here...

[Michael Ernest]

The architecture of this approach is exactly similar to the way inetd works in Solaris and other adopters of the Unix System 5 Release 4 (SVR4) operating standard.
Rather than have daemons for telnet, ftp, and other popular applications running all the time, they're kept dormant until they're called upon, keeping system resource usage to a minimum. When an initial call is made to a server for telnet, it's the inetd program that reads the pre-assigned port for telnet, "wakes" telnetd from its persisted state, and things go from there.
rmid does the same thing. While various activatable objects are napping, rmid is monitoring for activity on all their ports, waking them only on an incoming call. In the meantime, the registry just does its thing, supplying stubs, and makes no assumptions whatsoever about when the stub might be used. So you do need both to make that work.

[James Cook]

Yes I can understand that the Registry is listening for stubs and that RMID is waiting for requests to activate Activatables.
What I am asking is: why does the Tutorial advise you to start RMIRegistry and then RMID, when RMID has its own Registry?
I have an Activatable server that does NOT use a *separate* RMIRegistry program at all. It merely uses the RMI Registry contained internally inside RMID. Needless to say, it works absolutely fine, activating stubs and doing Naming.lookup()'s etc without any bother. In other words, it registers the activatable class using code like this
LocateRegistry.getRegistry(rmid_port).rebind(...
where rmid_port=1098, the port on which RMID runs on by default (and RMID is running on this port). Thus I don't need to run RMIRegistry at all, whether it be on default port 1099 or some other (but not 1098).
The separate RMIRegistry program does not even see the light of day!
However, if I kill off RMID, any client that has an activatable object connection gets that object restarted when RMID is re-started, but any client that has to do a Naming.lookup fails because the internal RMI Registry inside RMID has been created anew.
So, my theory is, that the tutorial asks you to start RMIRegistry, so that RMID can be killed off whenever you like and restarted and everything still works, including Naming.lookup, BECAUSE you have registered the Activatable on the RMIRegistry, and NOT with the RMI registry inside RMID, and therefore that the RMI Registry is still running and intact.
If this theory is true, then a client does a Naming.lookup which hits the RMIRegistry program on port 1099, NOT the RMID program which is listening on port 1098. So the question becomes "How does the separate RMIRegistry program (a) know that RMID is running, (and the port it is listening to) and (b) communicate with RMID to let it know that a request to activate an object has been made, in view of the fact that the record of the remote object in the registry has been recorded in a different program from the one running the Activator."
I hope this is clearer now to you. I am busy compiling the HTML help files for my program and I need to get this concept clearly across to the users, so any help would be appreciated.

[Michael Ernest]

I agree with your theory.
To answer a) rmiregistry doesn't verify that rmid is up and running. It doesn't care. A lookup service does not typically assure that the service is working, only that it at one time declared its availability through bind(),(or rebind() after a crash).
On b) I'll have to do a little more research to know what to say -- I sense a number of viable followup questions to what I think I might answer, so I might as well run down those paths first.

[roger wong]

I think the activatable remote object stub(get from registry 1099) contains the reference of the Activation System(rmid 1098).

It lies in the internal activation rmi architecture.