[omniORB-dev] Server support for ImR interfaces

[kendall bailey]

Thomas Lockhart wrote:

> Duncan has indicated that he would like to see no implicit support for 
> the ImR within the omniORB orb. So a server interacting with an ImR 
> would have explicit calls. What would a complete solution look like 
> from an application server point of view? I'd like to see a suggested 
> code snippet or at least a sequence of operations required by a 
> server. And this should include managing object and POA 
> startup/creation and shutdown/destruction, since those need to 
> coordinate with an ImR and could be initiated by either the ImR or by 
> the application server itself.


I think something like what you are asking for was posted to the omniORB 
list.  I posted a sequence of steps and Duncan patched it up a bit.


sequence:
1. server starts up.
2. server finds a reference to the ImR (either from command line or in 
configuration file or...)
3. server instantiates a ProcessManager and activates it
4. server sends ImR the persistent process name and the ProcessManager 
reference and receives a temporary identity from the ImR.

The temporary identity is my idea just to keep multiple servers from 
using the same persistent name and confusing the ImR.

At this point the server can start POAs, activate objects, register 
objects in a name service or whatever.  If the server is started in 
"prepare" mode, then:

5. server asks the ImR to create persistent references to any objects it 
wishes to puplish persistent references for.
6. server publishes the references (in a name service, to a file, to 
stdout, or wherever)

I'll inject some steps for replica groups here, but if you aren't 
interested, just skip it.
7. server activates replica instances.  How these replicas 
share/transfer state, if necessary, does not involve the ImR, except the 
ImR may be called on to get a list of all replica members.
8. server adds the replica object references to named groups known to 
the ImR.
9. The ImR returns the group persistent reference to the server
10. ImR stores the groups of replicas, so that invocations can be 
forwarded according to a balancing strategy.

When a client invokes on an ImR generated persistent reference:
11. ImR determines whether it is a replica group reference or not.  If 
so, it selects* a member and replies with a location forward.
12. Otherwise, the ImR determines the process identity, and checks to 
see if the process is up.
13. If not and the ImR can start it, then it does so.
14. Once the ImR has a reference to the appropriate ProcessManager, the 
ImR requests a direct reference based on the program and object identities.
15. server does whatever it needs to do (start POAs, activate objects, 
or whatever) to generate the reference and return it.
16. ImR returns a location forward to the client with the direct reference.

* The selection process may test object health and/or system load

Step 14 may take a while, if the server process needs to start up.  I 
was thinking part of registering a start command must also tell the ImR 
the acceptable time limit.  If no ProcessManager registers in that time, 
the client would get a TRANSIENT exception.

Step 15 may involve adapter activators, as I described in a previous 
post.  A C++ and/or Python library may be included with the ImR that 
clients can use to simplify the implementation of a ProcessManager.

Shutdown should be simple.  If the ImR is told to stop a server (I don't 
think I have an interface for that yet...), it fires the stop_command 
and waits.  If we have a ping() method I suppose it could keep pinging 
the ProcessManager until it fails, or give up and report an error. 
 Otherwise it waits for the ProcessManager to tell it that it's going 
down.  Any replica object known to be in that process are removed from 
any groups they are in.

Server processes can shut down any POAs any time they choose, or shut 
down completely.  The ImR does not act on POAs directly, just processes. 
 Processes should notify the ImR of shutdown.  If a process crashes, the 
ImR will need logic to determine when a restart should be attempted. 
 Getting OBJECT_NOT_EXIT during a call to the ProcessManager may be 
enough or we may need the ping() you mentioned.  The decision to fire 
the start_command should be configurable.

>
> I just reviewed the TAO docs for their ImR and notice that the 
> implementation changed recently to support a more distributed model 
> than before. They have the ImplRepo_Service application as always, but 
> now the ImR_Activator does most of the heavy lifting, with the 
> ImplRepo_Service being simply a single point of contact for a client, 
> then delegating the work to an ImR_Activator running on the host for 
> the target server. We should certainly examine the IDL associated with 
> these applications (actually, the files are ".pidl" since they require 
> a bit of massaging). For example, I was thinking about the need for 
> the ImR to test for the health of a server and notice that the TAO IDL 
> include a ping() method for just this purpose. And we should examine 
> IDL from other ORB implementations to get guidance where they overlap 
> with our goals.

I don't have TAO installed at the moment.  Could you post a link to just 
the IDL of interest, or just send it to me (or the list) directly if 
it's not too big?

Splitting responsibilities between a single service process and an 
additional process per host obviously has advantages.  I'd like to get 
an all-in-one solution working before federating the thing though.  For 
the first go, if the ImR needs to start a process on another host, I 
think the start_command should use rsh, ssh or something else to get the 
process going (as described in H&V).


Kendall