Aida Use of CORBA Implementation Repository

This page describes the use of the CORBA Implementation Repository, as implemented by Orbacus, for controlling Aida servers. Further documentation can be found in [3], chapter 7.

Using the IMR Console Glossary
Testing servers under IMR control Adding Aida servers to IMR control
Configuring the system for using the IMR  Prerequisites and peculiarities
Forward references Status

Summary

Using the IMR Console

The IMR console is a java program with a GUI that can be used to start, stop and monitor Orbacus servers status. See the Orbaucs manual under “The Implementation Repository Console”. In [3] its chapter 8.

Usage

OBIMR.jar must be your classpath in order to use it. Then at a prompt type:

java com.ooc.IMRConsole.Main -ORBInitRef IMR=corbaloc:iiop:<IMRHOST>/IMR

on NT you can type: IMRConsole.bat

Starting Aida Services with the IMR console

Having started the console, in the left hand pane open the "OAD" of the host on which you want to start a service. Highlight the service you want to start. If it is greyed-out that means its not presently running and it can be simply started - right click and select "Start..." from the pop-up window. If it is currently running it must be stopped  before it can be restarted - right click and select "Stop..." from the pop-up window, then hit start. 

Aida Startup procedure

Note that the Aida services must be started in a particular order. See the Aida Services Management Guide, Order of Activation . YOU must wait until you see the "Server Ready" message before activating the next service.

Testing Servers under IMR control

To run a test server

Running a test server amounts to starting the server with a different classpath

To use a test CLASSPATH for a server

Get a Start<server_name>Server.bat file for the server you want to start with your test CLASSPATH in a local directory. Edit it to insert a -classpath specification in the java command line. The classpath you specify should start with your development directory package root (the dir that contains "edu", and end with the predefined CLASSPATH, so that what is not found in your development directory is found in production. For instance: 

java -classpath Z:\Dev\projects\persist;%CLASSPATH% 
edu.stanford.slac.aida.generic.GenericServer 
-ORBconfig %AIDASCRIPT%\generic.conf 
-ORBInitRef IMR=corbaloc::%IMRHOST%:10000/IMR 
-ORBInitRef EventService=corbaloc::%EVENTHOST%:11000/DefaultEventChannel %*

Then use the instructions below to tell the IMR to use your test Start<server_name>Server.bat file instead of that in production. Note that, if the server runs on an NT workstation which can't see the code root you have set then you will have to move the server to your workstation. The IMR console can help you do that, or you can use imradmin commands --remove-server and add-server.  

To use a test server startup script

Without Using the IMR Console

Redefine AIDASCRIPT to the location of the test server startup script, then use imradmin to tell the IMR the new server startup script. The imradmin<servername>.bat files run the imradmin command to add a server to the imr.  AIDASCRIPT will be translated at the time that imradmin executes, not at the time IMR executes to start the server, so you can just run the appropriate imradmin<servername> script. Eg:

  1. Z:\>set AIDASCRIPT=c:\dev\aida\common\script   <-reset AIDASCRIPT
  2. If the server is already running, you'll need to shut it down before you can run imradmin to re-add the server. You can use imradmin --remove-server, or the IMR console Delete commad to shut doesn a server. If the server isn't running, just go to the next step.
  3. Z:\>imradminDa.bat   <-run imradmin<servername>.bat, which executes...

imradmin -ORBInitRef IMR=corbaloc::cdntwks17:10000/IMR --add-server da "c:dev\aida\common\script\StartDaServer.bat" cdntwks17

Using the IMR Console

In the IMR Console, highlight the server for which you want to use a test startup-script, then select Edit->Modify. Change the Execution Path to point to your test Startup Script.   

Hit refresh on your IMR console to see that your changes have taken effect. Then you can start or restart the server from the IMR console.

To change the default host of a server

1. Put the imr into administrative mode

imr –ORBconfig I:\package\aida\common\script\imr.conf –administrative

2. Excute imradmin commands to remove the server from the IMR, and then re-add it on a different host, eg, to move server “name” from its old host (wherever that was) to cdntwks4, type these two commands

imradmin –ORBInitRef IMR=corbaloc::<IMRHOST>/IMR –-remove-server name
imradmin –ORBInitRef IMR=corbaloc::<newhostName>/IMR –-add-server name “I:\package\aida\common\script\StartNameServer.bat” cdntwks4

To see which oads are running and where

Z:\>imradmin -ORBInitRef IMR=corbaloc::cdntwks17:10000/IMR --tree
domain
|-- MCC.SLAC.STANFORD.EDU  (down)
|-- cdntwks17  (up)
`-- cdntwks4  (down)

or use the IMR console, for which you need java.

To remove an oad from a server host

Z:\>imradmin -ORBInitRef IMR=corbaloc::<IMRHOST>:10000/IMR --remove-oad <oadHostName>

Use the –-tree arg, or the IMR console, to verify the oad has been removed.

 

Configuring the system for using the IMR

The following checklist gives the whole requirements list for setting up Aida servers for control under the IMR. It assumes no previous setup for this has been done, see above for a checklist for adding an individual server to IMR control once all of the following has been done. The following items correspond those listed with the same numbers in the Orbacus 4.0.5 Manual, section 7.5 "Getting Started with the Implementation Repository".

1. Determine Physical Architecture

At the time of writing we're running CORBA services on cdntwks17, slcs1 (the ca service), and MCCDEV (slc service). There is no oad executable available for VMS, so we can't control the slc service through the IMR on that. The IMR is being run on cdntwks17 in addition to the Aida services running there. So

mode dual slave
host cdntwks17 slcs1

2. Create a configuration file for the IMR and OADs

Write one (1) imr.conf, for the host running the IMR

ooc.imr.mode=dual 

put imr.conf in package/aida/common/script

Write one or more oad.conf. It may be that you can use the same oad.conf on each oad host 

Eg, For slcs, which is running the ca service:

ooc.imr.slave_endpoint=iiop --port 10001
ooc.imr.mode=slave

put oad<host>.conf in package/aida/common/script

3. Start the IMR in administrative mode

To start the IMR for host registry and so on, do the following for this step:

imr –ORBconfig I:\package\aida\common\script\imr.conf --administrative

3.1. Tell IMR about the OADs on the slave servers

imradmin -ORBInitRef IMR=corbaloc::%IMRHOST%/IMR --add-oad slcs1
imradmin -ORBInitRef IMR=corbaloc::%IMRHOST%/IMR --add-oad cdntwks17

The first of these tells the IMR running on IMRHOST that you intend to put servers on slcs1. It does not install or start running an OAD on slcs1. To do that you have to run imr on that host (not in admin mode), see 5. 

4. Start the OADs 

Run imr, with the ooc.imr.mode=slave property on each host that you want to run a server on (except the IMR host if that is in "dual" mode. Since we do not use the ooc.imr.service property in the conf files to tell the OAD which machine is hosting the IMR, we have to tell it using an -ORBInitRef. We use this method so that the IMR host can be changed at runtime without changing all the .conf files. Eg, for slcs1

imr -ORBconfig $AIDASCRIPT/oad_slcs1.conf -ORBInitRef IMR=corbaloc::%IMRHOST%/IMR

On slcs1 you can just $source ./StartOAD_slcs1.sh

Note, IMRHOST must be the full IP address (and on unix, uppercase it too). 

5. Add each server to the IMR

In Aida, the IMR activates each server by calling a startup script for that server. So the first thing to do is write the .bat and .sh file for each Aida server. Then write the imradmin<servername>.sh/.bat file that tell the IMR about your server and hwo to run it with the script.

6.1. Write the script that runs the server. The names of these shell script files will be the value of the  “exec” arg of the –add-server command to imradmin. Each .sh and .bat file starts the correct java main() class, and must include a –ORBconfig argument which points to that server’s CORBA properties file, and the -ORBInitRef to point back to the IMR. when the IMR invokes the server (by executing this script) it appends arguments: the server name, and the PID of the process. Those arguments should be handled by the shell script - that's why I've added the %* at the end of the "java" line. 

Note, put @echo off <- this seems to be very important, the IMR can’t start a server whose exec command is a bat file unless this is in the bat file!

CALL %AIDASCRIPT%\aidaSetEnvRuntime.bat
java edu.stanford.slac.aida.name.NameServer "-ORBconfig" %AIDASCRIPT%\name.conf "-ORBInitRef" "IMR=corbaloc::cdntwks17:10000/IMR" %*

For the slc server, the StartSlcServer.com file, and the slc.conf file must be on MCC.

6.2 Then write .bat file to run imradmin to register each server, and set its arguments Eg for name server

flora03> cat $AIDASCRIPT/imradminName.bat
imradmin -ORBInitRef IMR=corbaloc::%IMRHOST%/IMR --add-server name "I:\package\aida\common\script\StartNameServer.bat" cdntwks4

6.3 Run the imradmin<serverName>.sh/bat file to add the server to the imr.

slcs1> source $AIDASCRIPT/imradminCa.sh

6. Add each POA to the IMR

In our case the servers are registered without setting the activate_poas attribute, so it defaults to true. All persistent POAs will be registered automatically. See Orbacus 4.0.5 Manual, secn 7.1.2 (p116) under POAs.

7. Configure your servers to use the IMR

There are 3 ways to configure a server to use the IMR. We will be using option b) from ORBACUS 4.0.5 7.5-7, the “Use the –ORBserver_name command line option” because in our scheme the IMR is responsible for starting all the servers, and when the IMR starts a server, it automatically adds the –ORBserver_name option to the argument list. 

8. Create object references for use by the clients

We put the IORs into the database. The mkref utility just puts prints a reference to standard out, which isn't much use without more work.

9. Restart the IMR in non-administrative mode

ie, on the master just stop the imr and restart it w/o the --administrative arg.

Note, if using the ntimrservice, there is no administrative mode.

 

Adding an Aida server to IMR control

For when a new host is booted or brought online.

Summary for Slcs1

4 slcs1> imradmin -ORBInitRef IMR=corbaloc::<IMRHOST>:/IMR --add-oad slcs1
5 slcs1> source $AIDASCRIPT/StartOAD_slcs1.sh #this will not complete. Give it a few seconds before refresshing IMR console.
While all NT hosted services run on same host as IMR there's no need to start any OAD on an NT host.
6 slcs1> source $AIDASCRIPT/imradminCa.sh #Check this had effect by refresshing the IMRconsole
run imradminEvent.bat, imradminName.bat, imradminMagnet.bat, imradminGeneric.bat, imradminDa.bat 

If the oad for slcs1 is already is registed on the IMR (step 4), and the IMR db 
already knows that the ca server runs on slcs1 (step 6), then you need only need
start the oad on slcs1 (step 5). 

In detail

This list describes the steps for configuring the IMR so as to accept new Aida servers, configuring the host machine that is going to host the new Aida server, and starting the Aida server under the IMR.

1. Start IMR in administrative mode (see 3 above)

Z:\>imr --administrative –ORBconfig I:\package\aida\common\script\imr.conf

on NT you can type: StartIMRAdmin.bat

2. Start OAD on each host that is going to host a server under IMR control (see 4 above)

If there is already an OAD on the host for the server, you can skip this step.

NT servers: log into the host, and run the following at a DOS prompt. This will not complete.

Z:\>imr -ORBconfig I:\package\aida\common\script\oad.conf

on NT you can type: StartIMR.bat

Slcs1 server: source $AIDASCRIPT/StartOAD_slcs1.sh

3. Add each server to IMR (see 5 above)

This command is of the general form:

Z:\>imradmin -ORBInitRef IMR=corbaloc::<IMRHOST>/IMR --add-server name "I:
\package\aida\common\script\StartNameServer.bat" <serverHOST>

NT server you can type: imradmin<serverName>.bat
on Unix: source $AIDASCRIPT/imradmin<serverName>.sh

4. Start the server

Either start it with imradmin

imradmin -ORBInitRef IMR=corbaloc::<IMRHOST>/IMR --start-server name

or on NT you can type: StartServerName.bat, or from the IMR console, see next

5. Start the IMR Console to monitor the server

Z:\>java com.ooc.IMRConsole.Main -ORBInitRef IMR=corbaloc:iiop:<IMRHOST>/IMR

on on NT you can type: IMRConsole.bat

6. Test the server.

Start a client of the server.

 

Prerequisites and peculiarities

I:\package\aida\tool\win32\orbacus\Ooc\lib\OBIMR.jar is needed in the classpath if a java server is going to be started by the IMR.(hm, check this.)

You need to put –ORBserver_name arg in the .bat file which runs a java server, eg “-ORBserver_name” “name”, or include %* at the end of the arguments to the server, so the IMR can pass “–ORBserver_name name” to the server at startup. See a Start<server>Server.bat file for an example. And it might well be that the case has to exactly as it is here and each of –ORBserver_name and the name must be in doublequotes, as it is here.

There must be a “@echo off” at the top of a bat file that starts a java server (and maybe any kind of script file and maybe not just java servers). I found that servers would immediately exit when started from the IMR if the bat file the IMR executes did not have one of these at its head!

Difficulties

Using IMR on a VMS host

There is no IMR executable for VMS, so we can’t run the IMR on VMS to start the OADs.

Using IMR on an NT host

Making the IMR work on a host machine means all the DLLs that it uses must be available to the IMR on the PATH. The easiest way to ensure that for NT is to install Microsoft Visual C++ on that machine. Then execute \Program Files\Microsoft Visual Studio\VC98\bin\vcvars32.bat) to publicise the dlls to executables on that machine.

The ntimrservice

Doesn’t seem to work for things that must be done in administrative mode. Didn’t try it for non-administrative use. Here’s the checklist of what was done:

Execute RegUpdate HKEY_LOCAL_MACHINE imr.conf on the IMR host (my machine, cdntwks17)

Install ntimrservice on IMR master host

Start the ORBacus Implementation Repository service from the Services control panel.

You can't start the ntimrservice, and use the regular IMR from the command prompt on the same host. 

You can probably run the IMR in non-administrative mode using the ntimrservice, but to run it in administrative you have to run imr –administrative from the command prompt.

IMR and OAD management

When you stop and restart the IMR (say to change from administrative to non-administrative mode), it seems servers keep going, but the OADs can't be contacted by the IMR! I found I had to restart the OADs for them to be recognized by the restarted IMR.

When starting a server from the IMR console, if the server initialization hangs or otherwise stops, control is never returned to the IMR console! The console has to be ctrl-ced and restarted. 

 

Forward References

The IMR maintains a database in the directory specified by the ooc.imr.dbdir attribute (or -d param to teh IMR command). If that that db is on an AFS filesystem, the IMR won't be happy when tokens run out. So put the IMR db in an non AFS place.

Using the Implementation Repository doesn’t stop you having to create an object reference for the servant and put that somewhere. All you get is that the IMR accesses that object reference (in a file, or in our case in the db), and uses it to start the server. However, we should use URL style object references rather than simply “SOR”s in the db.

Servers under IMR control must have PERSISTENT cobra attribute.

The “exec” attribute in the “set-server” imradmin command for a Java server should be the shell script or bat file that runs the server (or exec is the java interpreter, and args attribute is class implementing the server (compatibility with 4.0.5)). See a imradmin<servername>.bat file for example.

We should use implicit registration of POAs. See [3] 7.5, item 6 (Add each POA to the IMR).

When you start servers remotely under the control of the IMR, you can’t see when they’ve finished initializing unless using the IMR console. This is particularly important for verification that they’ve put their IOR in the db (or otherwise published it). So servers started remotely should not be have to be started in a particular order (so as to make sure valifd IORs are in the db), but should each acquire an IOR if they don’t have a valid one. 

For NT based server hosts it would be best to use the ntimrservice, since that is an NT service and can be made to start automatically when the host is started.

Troubleshooting

See Aida Troubleshooting, the IMR

 

Status

We have to start the VMS based SLC server by hand, until we figure out how to run IMR on MCC.

We need to figure out how run IMR on flora, for the ca server

To do

Experiment with what happens if a server is started by IMR, and then started by hand.
DONE: You get 2 instances of the server

Look at publishing IOR though IMR.

 

Glossary for this documentation on the IMR

 


[Aida Home Page][SLAC Controls Software Group][ SLAC Home Page]

Author: Greg White, 24-Sep-2001
Modified by: name (incl mailto), dd-mmm-yy, short description; name dd-mmm-yy, short description ...