[OPUS]

Frequently Asked Questions

OPUS Servers

OPUS SERVERS

What are the OPUS servers?

The servers are beta products new to the OPUS system as of version 3.2. These 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 v3.2 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.

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. The only way to stop them is to kill each server process, which should only be done when necessary (e.g., to reconfigure the system) and never when pipeline processes or managers are running.

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

You need to create and configure a .rhosts (or .shosts if you plan to you ssh instead) file on all nodes that will run OPUS.

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 (opus_env_server, opus_bb_server, opus_event_server). Kill any processes found starting first with the pipeline processes, then ending with the servers. It is important to kill the processes first since they can cause a new server to start if you kill a server while they are running.
  2. check that the contents of resource.locks in OPUS_HOME_DIR is empty. Any entries should be removed.
  3. check for lines containing ".STARTING" in OPUS_DEFINITIONS_DIR:opus_corba_objs. Remove any lines with ".STARTING" appended to an item in the first column.

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. 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