Log Output Targets

Developers can select the output target for log statements. Application programs can use one of three mutually exclusive targets.

Log Targets
Log Target Description
Default Log Target Output all log statements to stderr.
Log Files in Rotation Output all log statements to a set of rotating log files.
Log Callback The program defines a callback, which intercepts all log statements.

Each program process may set its log target only once. Attempting to set it again is an error.

Default Log Target

If a program does not set a log target, TIBCO FTL software directs all log statements to stderr.

Log Files in Rotation

Rotating log files organize log output into a set of files, and limit the file system storage that log statements can consume.

The call that arranges rotating log files accepts a file prefix, the file size that triggers rotation, and the maximum number of files.

Log files receive filenames consisting of the prefix you supply, a dot (.) character, and an integer suffix. Suffix zero indicates the current log file. Suffix 1 indicates the next most recent. Higher suffixes indicate older files.

Rotating renames each file in the set by incrementing its numeric suffix. If rotating would exceed the maximum number of files, then it discards the oldest file. These file I/O operations can affect message latency.

The TIBCO FTL library requires that the total length of any log file name must be strictly less than 1024 characters. The host computer’s operating system may require a smaller file name length.

Log Callback

Applications can define and register a log callback. Instead of directing log statements to the file system, the TIBCO FTL libary invokes the callback to process each log statement (that is, to enter it into the application’s log system).

This type of target can introduce overhead costs and potential latency.

Warning: Log Callback Restrictions
  • Programmers must ensure that the callback always returns promptly. The log callback executes inline, that is, synchronously, and can affect message latency.
  • Your callback must not call any TIBCO FTL API entry point.
  • Your callback must be thread-safe.
  • For best results, your callback must not acquire any lock that might require a long wait time.