Latency configuration

These Liberator configuration items allow Liberator to add timestamps to objects for the purpose of latency measurement.

Because Liberator is a Datasource application, you can also set the DataSource latency chain configuration items.

Contents:

timestamp-field

timestamp-field specifies the name of a field that Liberator should add to an update message, if the field is not included in the update. The timestamp field is only written to on update; the field is not updated each time the object is requested from Liberator’s cache.

When you want to measure the latency of data propagation through the Caplin Platform, you typically add a timestamp to updates within the component where the update records are first created — usually in the Integration Adapter that’s the source of the data. Defining a timestamp-field for the Liberator allows objects that didn’t originate from an Integration Adapter to be time stamped as well.

This timestamping feature won’t overwrite an existing field in the update message. So, if you set timestamp-field to the same field name used for recording latency-chaining timestamps, you avoid Liberator won’t duplicate rttpd_E timestamp.

This timestamping facility is independent of the latency chain timestamps, and it isn’t controlled by the value of the latency-chain-enable configuration item.

This configuration item is overridden by the timestamp-field option of add-object for that particular object only.

By default, the value of timestamp-field is null (unset), and Liberator only writes timestamps to objects that have been defined by add-object and have the timestamp-field option specified.

Timestamp format and precision
Liberator version Format Example

< 7.1.0

Milliseconds since 1 Jan 1970

1509967184123

7.1.0

Microseconds since 1 Jan 1970

1509967184123456

> 7.1.0

Seconds since 1 Jan 1970, with a nanosecond fractional component

1509967184.123456789

Syntax: timestamp-field <field-name>

Type: string

Default value: null

See also: