Round Robin Framework Architecture

Configuration Processing

The XML configuration is compiled into the database representation by operator's manual request.

The compiled version of the configuration is not a one-to-one representation of the XML version. All aliases and templates are expanded. Thus, the backwards restoration of XML from the database is possible, but is not our urgent task.

Aliases are the way to represent the data in a more convinient format. An alias can point to a subtree or a leaf, and it works similarly as a symbolic link in a filesystem.

A template defines a piece of configuration which can be used in multiple places. Templates and aliases are not supported within a template.

The configuration can consist of several XML files. They will be processed in the specified order. Each new file is treated as an additive information to the existing tree.

The configuration processing module should contain information about parameter dependency and mandatority. Should the mandatory parameter be missing, the configuration processing should stop with an explanative error message.

Database Architecture

All runtime data is stored in Berkeley DB database environment (

The compiled version of the configuration XML is stored in the ds_config_INST.db and other_config_INST.db. These databases have similar structure, and ds_config_INST.db keeps all datasource-related information. INST stands for the productive instance number, and has value 0 or 1. Current productive instance numbers are stored in db_config_instances.db database.

For each datasource tree, the database files are resided in $RRFW_HOME/var/db/sub/>tree_name< directory.

The runtime modules access the configuration via ConfigTree objects.

Each datasource subtree or leaf is identified by a token. Token is a short string of word characters, generated internally. Two types of tokens are recognized: single tokens and token sets.

Single token starts with letter T. The rest is a number of decimal digts.

Token set name starts with letter S. The rest is an arbitrary sequence of word characters.

The special token SS is reserved for tokensets list. Also tokenset parameters are inherited from this token's parameters.

View and monitor names must be unique, and must start with a small letter.

db_config_instances.db is a Hash database, with keys of form ds:>tree_name< or other:>tree_name<, and 0 or 1 as values.

ds_config_INST.db is a Btree database, with the keys and values defined as follows:

other_config.db is a Btree database, with the keys and values defined as follows:

aliases.db is a Btree database with aliase paths as keys and target tokens as values. It is used for quick alias expansion.

tokensets.db is a Hash database containing the token sets. The keys and values are as follows:

nodepcache.db is a Btree database containing the cached node parameter values. The keys and values are as follows:

config_readers.db is a Hash database which contains the informaton about active processes which read the configuration. The configuration compiler waits until all readers finish using the current configuration database. Process IDs are used as keys, and the values contain timestamps.

timestamps.db is a Hash database containing various kinds of timestamps. The timestamp name is the key, and the number of seconds since epoch is the value.

render_cache.db keeps the status information about the graphs ready to display. Last known timestamp of the configuration is compared with the actual one. When the actual timestamp differs from known, the renderer cache is cleaned up. This is a Hash database, with the following keys and values:

monitor_cache.db is a Hash database used in order to avoid the unneccessary configuration tree walk. The keys are the leaf tokens, and the values are comma-separated monitor names. At each monitor invocation, the confguration timestamp is compared against the last known, and the cache database is rebuilt if needed.

monitor_alarms.db is a Hash database that keeps alarm status information from previous runs of Monitor, with the keys and values as follows:

collector_tokens.db is a Hash database used in order to avoid the unneccessary configuration tree walk. Keys and values are as follows:

scheduler_stats.db is a Btree database which stores the runtime statistics of Scheduler tasks. Each key is of structure <taskname>:<period>:<offset>:<variable>, and the value is a number representing the current value of the variable. Depending on variable purpose, the number is floating point or integer.

users.db is a Hash database containing user details, passwords, and group membership:

acl.db is a Hash database containing group privileges information:

Modular Structure

The Framework will consist of several functional modules:


Copyright (c) 2002-2004 Stanislav Sinyagin