Object configuration (part 2)

Here are the rest of the Liberator configuration items that define how Liberator deals with objects.

For an introduction to these configuration items, see Object configuration (part 1).

The object-related configuration items covered on this page are:

 And the configuration item detailed in Object configuration (part 1) is:

The following object configuration items about throttling are detailed in Throttling configuration:

active-discard-timeout

active-discard-timeout specifies the time in seconds for which the Liberator holds on to an object after the last user stops viewing it. If the object is a directory, the timeout doesn't begin until the last user has stopped viewing the last object in the directory.

This item is overridden for specific objects by the discard-timeout option of add-data-service for the data service that supplies the object. The discard-timeout option of add-object for a specific object overrides both the data service discard-timeout option for the object and active-discard-timeout.

Syntax:

active-discard-timeout <time-in-seconds>

Type: integer

Default value: 60 seconds

object-delete-batchtime

object-delete-batchtime specifies the time in seconds over which Liberator puts objects marked for delete into a particular batch.

Also see object-delete-time.

Syntax:

object-delete-batchtime <time-in-seconds>

Type: float

Default value: 0.5 seconds

object-delete-time

object-delete-time specifies the time in seconds after which Liberator deletes a batch of discarded objects.

Also see object-delete-batchtime.

Syntax:

object-delete-time <time-in-seconds>

Type: float

Default value: 5 seconds

object-map

object-map maps an object name to a different object name. 

Syntax:

object-map <existing-object-name> <new-object-name>

Type: string

Default value: [none] But the object-map item is not mandatory.

Mapping enables a client subscription for a given subject to be mapped to a different subject. Liberator can then request the new subject from another DataSource application, such as Transformer or an Integration Adapter. This enables multiple clients subscribing to the same thing to be mapped onto different streams of data, or multiple clients subscribing to different things to be mapped onto the same stream of data. The client is unaware that this mapping takes place, unless the data itself gives it away.

The strings defining <existing-object-name> and <new-object-name> can contain the following string-substitution tokens.

Substitution tokens
Substitution Token Description
%n A numbered capture group, where n is a number from 1 to 9. Used in both the <existing-object-name> and <new-object-name> parameters.
%u The user's username. Used in the <new-object-name> parameter to create an object name unique to the user.
%U The user's session name. Used in the <new-object-name> parameter to create an object name unique to the user's session.
%{CUSTOM_VAR} KeyMaster mapping variable. Used in the <new-object-name> parameter to create an object name containing a value collected at login. For more information on how to pass mapping data from KeyMaster to Liberator, see the class AuthenticationParameters in the KeyMaster API.

Examples of object-map usage:

Example 1:

object-map "/ABC/%1/%2 "/DEF/%2/%1"

This mapping changes the object called /ABC/EUR/FX to an object with the name /DEF/FX/EUR

Example 2:

object-map "/MYCHANNELS/%1 "/CHANNELS/%u/%1"

If a user called alice requests an object called /MYCHANNELS/ABC, the above object mapping changes this name to /CHANNELS/alice/ABC, creating a name that's unique to alice. When another user called bob also requests /MYCHANNELS/ABC, the request is changed to one that's unique to bobCHANNELS/bob/ABC

Example 3:

object-map "/MYCHANNELS/%1" "/CHANNELS/%U/%1"

Asume a user called alice is logged on to the Liberator twice, and the Liberator has generated a unique login name of alice-1 for the first session, and alice-2 for the second session. In the second session alice requests an object called /MYCHANNELS/ABC. The above object mapping changes this name to  /CHANNELS/alice-2/ABC This distinguishes the request from one made for /MYCHANNELS/ABC in the first session, which would have been mapped to /CHANNELS/alice-1/ABC

object-monitoring-interval

For the definition of this configuration item, see object-monitoring-interval in DataSource monitoring configuration.

record-clear-type1-on-failover

record-clear-type1-on-failover when TRUE, clears all type 1 data for active (subscribed) objects when Liberator fails over to a new DataSource peer or reconnects to the same peer.  This allows Liberator's cached data to be refreshed from the new / reconnected DataSource peer.

Syntax:

record-clear-type1-on-failover
or
record-clear-type1-on-failover TRUE

Type: boolean

Default value: FALSE (Type 1 data in Liberator's cache is not refreshed after failover or reconnection to a new DataSource peer.)

record-clear-type2-on-failover

record-clear-type2-on-failover when TRUE, clears all type 2 data for active (subscribed) objects when Liberator fails over to a new DataSource peer or reconnects to the same peer.  This allows Liberator's cached data to be refreshed from the new / reconnected DataSource peer.

Syntax:

record-clear-type2-on-failover
or
record-clear-type2-on-failover TRUE

Type: boolean

Default value: FALSE (Type 2 data in Liberator's cache is not refreshed after failover or reconnection to a new DataSource peer.)

record-clear-type3-on-failover

record-clear-type3-on-failover when TRUE, clears all type 3 data for active (subscribed) objects when Liberator fails over to a new DataSource peer or reconnects to the same peer.  This allows Liberator's cached data to be refreshed from the new / reconnected DataSource peer.

Syntax:

record-clear-type3-on-failover
or
record-clear-type3-on-failover TRUE

Type: boolean

Default value: FALSE (Type 3 data in Liberator's cache is not refreshed after failover or reconnection to a new DataSource peer.)

record-type2-hash-size

record-type2-hash-size specifies the size in table entries of the Liberator hashtable that's used to access cached Type 2 data.

Syntax:

record-type2-hash-size <hashtable-size-in-entries>

Type: integer

Default value: 65536 entries

record-type3-history-size

record-type3-history-size specifies the maximum number of updates to keep for each record containing type 3 (historic) data.
This item can be overridden for a specific object or object hierarchy by a record-type3-history-size option in an add-object configuration entry.

Syntax:

record-type3-history-size <maximum-number-of-updates>

Type: integer

Default value: 10 updates


See also: