This is a required property. It is a provider-specific string that is used to group together distributed store nodes that communicate with each other and share data. Store objects with the same clusterName value should operate as a single cluster, sharing data between them, whereas stores with different clusterName values should operate independently if possible.

For providers such as Terracotta/TCStore that use other configuration properties to indicate which components to connect to, the clusterName is just a display name used in log messages with no impact on behavior.

For BigMemory Max, the clusterName is a comma-separated list of host:port pairs that identify the servers in the Terracotta Server Array.

Care should be taken to ensure that different clusters, and thus clusterName values, are used for development/testing and production environments, as serious errors would be introduced if the production and testing nodes were able to communicate with each other. For the Terracotta/TCStore driver, this is not a concern as it is only a display name. The BigMemory Max driver makes it easy to avoid this pitfall since it requires a list of host:port. However, if you are using another driver, then for this reason, as well as whatever firewalls may exist between development/testing and production, the recommendation is to explicitly add a suffix such as _testing or _production to the clusterName to indicate clearly to which environment it belongs.

This is an optional property. The default is provider-specific, but is typically the same as the correlator log level.

The logLevel property is an Apama log level string (compatible with com.apama.util.Logger) such as ERROR, WARN, INFO, DEBUG which is used to set the log level for the provider if possible (some providers write to the main correlator log file, through log4j or the Apama Logger, but others may write to a separate file).

If not specified, the default log level is determined by the author of the driver, based on the criteria of avoiding the correlator log or stdout being filled with third-party distributed store messages while logging a small number of the most important messages.

This is an optional property. The default is 1.

The backupCopies property specifies the number of additional redundant nodes that should hold a backup copy of each key/value data element. The minimum value for this property is 0 (indicating no redundancy, that is, all data is held by a single node).

Note that some providers may allow customizing the backup count on a per-table basis, in which case this property specifies an overridable default value for tables that do not specify it explicitly.

For BigMemory Max, this setting has no effect. The number of backup copies is determined by the Terracotta Server Array configuration, which is separate from the Apama configuration.

This property is not used by the TCStore driver.

This is an optional property.

The initialMinClusterSize property specifies the minimum number of nodes a cluster must have before the Finished event is sent in response to a call to prepareDistributed. This provides a way to make sure that a cluster is fully ready for correlator nodes to request and process data.

The default is 1, which specifies that a Finished event is sent without waiting for additional nodes when preparing the distributed store.

This property is not used by the TCStore driver.

This property indicates whether the old value is required when there is a notification that a row has changed. The default is true.

If set to false, the value of oldFieldValues is empty for RowChanged.changeType.UPDATE events.

If set to true, the previous value is available. This cannot be set to true for TCStore or BigMemory Max.

This is an optional property.

The enforceApamaSchema property sets whether Apama creates a special table to record the schema of each table and use it to prevent opening a table with a different Apama schema to the previously used schema.

The default for most drivers (except TCStore) is to enable this checking to provide early warning of unexpected version mismatch issues. If a mismatch is detected, you should manually delete all tables used by Apama from the distributed store, typically using the delete command from the file system or tools provided by the distributed store. Note that this check provides no protection against non-Apama clients adding data that does not match the expected schema.