CDF connection

The Rf Control Resource Adaptor (Rf Control RA) will connect to the CDF when it is active. An alarm is raised if the Rf Control RA fails to connect to the CDF. There are several possible reasons connecting to the CDF may fail, including:

  • Incorrect diameter configuration of the Rf Control RA

  • There is a problem with the network

  • The CDF is not accepting connections

  • The host machine the Rf Control RA is running on is not properly configured

The alarm is automatically cleared once the failure is resolved, and the Rf Control RA successfully connects to the CDF.

Disk buffer management

The Rf Control RA uses an SQLite database as a disk buffer when the CDF is not reachable. SQLite is a simple, embedded, SQL database engine ideally suited to be used as an on-disk buffer.

Tip For more information on SQLite see www.sqlite.org

The database name is: buffer-<ra entity>-<rhino node>.db. Example: buffer-rf-control-ra-101.db.

The location of the database is defined by the Rf Control RA Diameter Configuration profile parameter OnDiskBufferDirectoryName (default value is ${rhino.dir.home}/rf-control)

Accounting Request (ACR) messages are stored in the database when the CDF is not reachable.

As a rule of thumb, assume 3kB per ACR (large but reasonable) and 3 ACRs per call (START, INTERIM, STOP). Assuming 500 call attempts per second per Rhino node, the database will grow at a rate of:

  • 4.5 MB per second

  • 270 MB per minute

  • approximately 16 GB per hour

If the Rf Control RA fulls the entire disk partition it is buffering to, an alarm of type write-failure or write-thread-failure will be raised (depending on the cause). The write-failure alarm will be cleared when the database is available for writing. The write-thread-failure alarm will require a Rf Control RA restart.

Note The platform operator is responsible for increasing the available disk space

During the write-failure and write-thread-failure condition the Rf Control RA will store ACR records in a memory buffer. If the database or the CDF connection issue is not resolved, the memory queue will eventually become full and the Rf Control RA will start discarding records.

When the CDF becomes available again, the Replay thread will attempt to transmit stored ACR records. The database will automatically re-use the disk space that successfully replayed ACR records had occupied.

Tip The number of stored and transmitted records can be monitored by viewing the RF Control RA’s statistics.

The SQLite database supports VACUUMING, which rebuilds the database file, repacking it into a minimal amount of disk space. VACUUMing is only necessary if the disk partition that the database is stored in is too small for normal operation use. For example, the database fits into the partition but the database size is deemed "too large". This procedure is nevertheless attempted automatically after all the records have been replayed by the replay thread, that is the database is nominally empty, since the impact on performance in this case is negligible. However, this attempt may fail if there happens to be a concurrent access to the database by another thread. This means that manual intervention may be necessary if disk space is getting low.

The database has incremental vacuum support enabled, since running an incremental vacuum should have less of a performance impact than a full one if there are a lot of records in the database, but it may be less effective.

An incremental vacuum procedure can be performed as follows:

$ sqlite3 buffer-rfcontrol-101.db "PRAGMA incremental_vacuum;"

or

$ sqlite3 buffer-rfcontrol-101.db
sqlite> PRAGMA incremental_vacuum;
sqlite> .quit

If this doesn’t produce the desired results, a full VACUUM procedure can be performed as follows:

$ sqlite3 buffer-rfcontrol-101.db "VACUUM;"

or

$ sqlite3 buffer-rfcontrol-101.db
sqlite> VACUUM;
sqlite> .quit
Note The vacuum procedure may fail if there is concurrent access to the database. To guarantee a successful vacuuming the Rf Control RA may have to be deactivated before performing the procedure.

For more information on VACUUM see SQLite VACUUM.

We recommend that the disk partition is large enough to not require VACUUMing.

If the operator has an independent alarm configured to monitor the disk partition use, then it is possible that a VACUUM may be necessary to reduce the reported disk usage (after a CDF outage and replay completion). Such an alarm should clear once the VACUUM has completed.

Previous page Next page