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_env_server: Provides the Java managers access to a user's
- opus_bb_server: Hosts a new, in-memory caching blackboard.
- opus_event_service: Hosts an event channel over which blackboard events
are pushed to the managers.
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
value to either
CORBA after making sure
all processes, managers, and servers are shut down. The default value of
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
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
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:
- Add to your environment (probably in opus_login.csh): "setenv OPUS_USER_PORT (a single number in that port range)"
- Add the following arg-pair towards the end of each server/service line in opus_corba_objs: "-ORBEndpoint iiop://tux.stsci.edu:21000/portspan=500" (though of course put in your own machine name and port range. This example uses ports 21000-21500 on machine tux)
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
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
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
.rhosts file on all nodes that will run OPUS.
If you plan to use ssh, you need to
create and configure
.shosts file instead, and you need to set the
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
What do I have to do before manually restarting the servers after a
Some cleanup might be necessary before attempting to run opus_server_monitor
again. Perform the following tasks prior to attempting a restart:
- 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.
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?
TAO (The ACE ORB) package is used by OPUS for most of the required CORBA
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:
- Issues of persistence addressed: Currently, the servers are designed to
stay up forever; there is no mechanism for shutting them down, short of
killing the processes. A means of cleanly shutting down the servers will be
implemented in a future release.
- Manual refresh of the blackboard cache: When BB_TYPE is set to CORBA, a
caching blackboard is used by opus_bb_server to reduce I/O overhead and to
improve performance. Since the cache is in physical memory, manual changes to
the persistent disk store are not reflected in the cache (moreover, they could
potentially cause problems with the server). A means of signalling the server
to reload its cache is planned for a future release.
- Usage statistics: Both the user context and blackboard servers support an
interface for gathering server-usage information. A tool for collecting this
information is planned for a future release.
- FILE versus CORBA mode performance & scalability test results: Formal
testing of how much more scalable OPUS is when running in CORBA mode versus
FILE mode have yet to be performed. These tests, and some measure of the
performace consequences of CORBA mode are planned for the future.