Introduction

This document describes the changes made to CMLOG client code at SLAC, which was originally changed to support a different style of message throttling than the one originally built in to the CMLOG client.

First off, old JLAB calls should still work the same as before, which is to maintain a history of unique field values and throttle on each of those seperately. No provision was provided to specify specific values of special interest to throttle; the system would just allow a certain number of *each* value through.

The new implementation reformulates the old cmlogFilter:: class into a base class extended by the new classes cmlogFilterNull, cmlogFilterJLAB, and cmlogFilterSLAC (the non-filter, the JLAB-style filter, and the new SLAC filter, respectively). The application must now explicitly create the desired filter, as described below, and pass it to the cmlog client. If no filter is explicity set up, it defaults to the old JLAB filter, or whatever is specified in "-D_DEFAULT_FILTER=" in the client makefile (set to "cmlogFilterSLAC" for SLAC).

The SLAC filter supports filtering on specific contents of tags (fields) of a message. A throttle "limit" specifies the number of messages desired per time period ("deltaTime"), and throttles may be re-started at any time with different limit and time-period parameters.

In addition, summary messages are output when throttles are started & stopped, and after throttling has resulted in messages being dropped, and a function is provided for displaying the current list of throttles.

The more recent changes to the SLAC filter include the addition of a threaded option which outputs status messages based on time and independent of the client applications; and also a revised throttle timing scheme, modified throttle behavior and modified content of throttle status messages.