# 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)](liberator-object-configuration-part-1.md), [Throttling](liberator-throttling.md), and [Throttling Configuration](liberator-throttling-configuration.md). ## 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](../datasource/datasource-directories.md), 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](../datasource/datasource-data-services-configuration.md#discard-timeout) option of [add-data-service](../datasource/datasource-data-services-configuration.md#add-data-service) for the data service that supplies the object. The [discard-timeout](liberator-object-configuration-part-1.md#discard-timeout) option of [add-object](liberator-object-configuration-part-1.md#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 ` **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](#object-delete-time). **Syntax:** `object-delete-batchtime ` **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](#object-delete-batchtime). **Syntax:** `object-delete-time ` **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 ` **Substitution tokens supported in <existing-object-name> and <new-object-name>** | Substitution Token | Description | | --- | --- | | `%__n__` | A numbered capture group, where `__n__` is a number from 1 to 9. Used in both the `` and `` parameters. | | `%u` | The user’s username. Used in the `` parameter to create an object name unique to the user. | | `%U` | The user’s session name. Used in the `` parameter to create an object name unique to the user’s session. | | `%{CUSTOM_VAR}` | KeyMaster mapping variable. Used in the `` 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](https://docs.caplin.com/developer/api/keymaster/latest/com/caplin/keymaster/AuthenticationParameters.html) in the KeyMaster API. | **Type:** string **Default value:** [none] **Examples:** **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 `bob`: `CHANNELS/bob/ABC` **Example 3** ``` 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](../datasource/datasource-datasource-monitoring-configuration-part-1.md#object-monitoring-interval) in [DataSource monitoring configuration](../datasource/datasource-datasource-monitoring-configuration-part-1.md). ## record-clear-type1-on-failover `record-clear-type1-on-failover` when `TRUE`, clears all [type 1 data](../datasource/datasource-type-1-data.md) 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 ` **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](../datasource/datasource-type-2-data.md) 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 ` **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](../datasource/datasource-type-3-data.md) 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 ` **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](../datasource/datasource-type-2-data.md). **Syntax:** `record-type2-hash-size ` **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](../datasource/datasource-type-3-data.md). This item can be overridden for a specific object or object hierarchy by a [record-type3-history-size](liberator-object-configuration-part-1.md#record-type3-history-size) option in an [add-object](liberator-object-configuration-part-1.md#add-object) configuration entry. **Syntax:** `record-type3-history-size ` **Type:** integer **Default value:** `10` updates --- **See also:** * Reference: [Object configuration (part 1)](liberator-object-configuration-part-1.md) * Reference: [Throttling configuration](liberator-throttling-configuration.md)