Object configuration (part 2)
Here are the rest of the Liberator configuration items that define how Liberator deals with objects.
More object-related configuration items can be found in Object configuration (part 1), Throttling, and 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.
Mapping enables a client subscription to 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 subject to be mapped onto different streams of data, or multiple clients subscribing to different subjects 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.
Syntax: object-map <existing-object-name> <new-object-name>
| Substitution Token | Description |
|---|---|
|
A numbered capture group, where |
|
The user’s username. Used in the |
|
The user’s session name. Used in the |
|
KeyMaster mapping variable. Used in the |
Type: string
Default value: [none]
Examples:
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
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 bob: CHANNELS/bob/ABC
object-map "/MYCHANNELS/%1" "/CHANNELS/%U/%1"
Assume 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 <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
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
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
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:
-
Reference: Object configuration (part 1)
-
Reference: Throttling configuration