Object configuration (part 2)

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 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 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 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.

Examples of object-map usage:

Example 1:

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

Example 2:

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 bob: CHANNELS/bob/ABC

Example 3:

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

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

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 <boolean>

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 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 <boolean>

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 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 <boolean>

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 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 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: