[OPUS]

Frequently Asked Questions

OPUS Servers

OPUS SERVERS

What are the OPUS servers?

The servers were initially introduced to the OPUS system as of version 3.2. They are much more fully tested and configured in the current release of OPUS. The servers provide an alternative implementation and communication mechanism between OPUS processes and the managers and the blackboards. There are three types of OPUS servers:

Communication between the servers and the Java managers and pipeline processes is based primarily on CORBA object method calls.

What is meant by beta products?

The servers are a work-in-progress and do not yet contain all of the functionality that is planned for them. As a consequence, they are more difficult to setup and monitor than they will be in final production form and significant changes to their interfaces are still possible. Although they have been thoroughly tested prior to release as beta products, our experience with them is limited as of yet. Performance tuning also remains to be completed.

When must I use the servers?

Always. With the addition of the servers, OPUS now can be operated in one of two modes: FILE or CORBA. The FILE mode corresponds to the pre-3.2 releases of OPUS where applications directly interface to the file system in order to access blackboard content; the servers are not accessed by pipeline applications in this mode. However, the Java managers still communicate with the servers to accomplish their tasks.

In CORBA mode, the pipeline processes also use the servers to access blackboard content. Since all blackboard traffic passes through the servers in this case, in-memory caching blackboards replace the default file system implementations in CORBA mode.

You select which mode (FILE or CORBA) to operate in by overriding and editing the file OPUS_DEFINITIONS_DIR:opus.env: change the BB_TYPE value to either FILE or CORBA after making sure all processes, managers, and servers are shut down. The default value of BB_TYPE is FILE.

What are the advantages of running in CORBA mode?

When all blackboard transactions pass through the servers, it is possible to reduce the amount of file system loading imposed by OPUS on the system. For example, read-only operations on a blackboard (e.g., a process polling for work to do) need not touch the file system at all when the caching blackboards are employed. Moreover, since the servers see every change on the blackboard as it occurs, it is possible to generate events for the managers immediately without having to poll the entire contents of a blackboard looking for changes at regular intervals (as is done in pre-3.2 releases of OPUS and in the current version when run in FILE mode). Reduced loading of the file system will allow OPUS to scale to much larger numbers of processes per pipeline without compromising operating system reliability.

What are some possible disadvantages?

Although serious performance analysis and tuning has yet to be performed for the servers, it is highly likely that the caching blackboard implementations will exact a greater overhead on processes than the file system blackboards. Unlike file systems that are part of the base operating system, the servers are not optimized for I/O throughput nor do they run with any special scheduling or priority.

A basic assumption is made that a typical OPUS application spends far more time performing its specific task once triggered than interacting with the blackboards. In other words, the jobs undertaken by pipeline processes are non-trivial. If this is not the case, running in CORBA mode might degrade performance over an equivalent system run in FILE mode.

Do I need special privileges to run the servers?

No. The servers were designed to run from an OPUS user's account without special privileges. Every user has their own set of servers.

How do I configure the servers?

The commands used to start the servers are located in the file OPUS_DEFINITIONS_DIR:opus_corba_objs. This file also contains (or will contain after running the system) mappings between corba object names and object types. The OPUS system automatically updates the object mappings, and you should not alter them. However, the server command-line section of this file can be tailored to suit your needs.

A template file, opus_corba_objs_template, with instructions for setting the server command-lines is located in the OPUS distribution under definitions/unix. A copy of this template is moved into your sample pipeline definitions directory during installation and renamed to opus_corba_objs. Although the template contains usable settings, you might want to customize how your servers are run. Consult the template file for instructions on how to do so.

Note that all comments in your copy of opus_corba_objs will be removed at run-time.

NOTE: There is a special argument set that can be used on the end of each server/service line in opus_corba_objs in order to handle running the servers using specific ephemeral port ranges (e.g. for machines running a firewall or with other network restrictions). To implement this, perform both of these items, and then restart your servers:

How do I start and stop them?

With one exception, starting the servers is automatically managed by the system. The exception is opus_env_server, which must be manually started by the user. This is done by running the utility opus_server_monitor. If opus_env_server is not running when opus_server_monitor is run, an instance will be started; otherwise, opus_server_monitor does nothing.

Once started, the servers are meant to be run continuously without stopping. If there is ever any need to stop them (which should only be done when necessary, e.g., to reconfigure the system), they can be brought down automatically (only when all pipeline processes and managers are terminated by the user) via the  kill_oservers.csh  script.

Note that this script spawns two Perl scripts, which assume the Perl interpreter is located at /usr/local/bin/perl. If this is not the location of Perl on your system, you may edit the first line of any installed OPUS Perl scripts to change this.

Why do I get a "Permission denied" error when I try to start the servers?

You need to create and configure a .rhosts file on all nodes that will run OPUS.

If you plan to use ssh, you need to create and configure a .shosts file instead, and you need to set the OPUS_REMOTE_SHELL environment variable.

What happens if a server crashes?

In the case of opus_bb_server and opus_event_service, new instances will be started automatically by the system once it is discovered that they have crashed. However, if this happens, managers up at the time must be restarted since they will have obsolete references to these servers. The same applies should opus_env_server crash; this server must be restarted manually using opus_server_monitor, and any managers running at the time restarted.

What do I have to do before manually restarting the servers after a problem?

Some cleanup might be necessary before attempting to run opus_server_monitor again. Perform the following tasks prior to attempting a restart:

  1. Check all nodes in the OPUS system for running instances of the managers, pipeline processes and servers. Kill any pipeline processes found. It is important to kill the processes first (before the servers) since they can cause a new server to start when needed.

  2. Run  kill_oservers.csh. This will bring down the servers and make sure all server-related files are in the correct state for eventual restart.

Are the servers secure?

To a large extent. The managers must use an account name and password in order to establish communication with opus_env_server, which serves as proof of identity. This initial connection can be done via FTP or SFTP. The CORBA object references stored in OPUS_HOME_DIR:opus_iors are protected by file permissions established on that file. Future versions of the servers will employ SSL.

What CORBA package does OPUS use?

The TAO (The ACE ORB) package is used by OPUS for most of the required CORBA infrastructure. Refer to the README and licensing files for specific information on versions. The built-in CORBA capabilities of Java also are used.

What enhancements can I expect to the servers in the future?

Capabilities planned for the servers that are not yet (fully) implemented in the beta versions include:

Top of SERVERS FAQ

Top of OPUS FAQ