Runtime Application Configuration

Build to use when executing your application; this property is used only during the boot process. Do not change the default value PRODUCTION unless instructed by TIBCO Support to diagnose problems. DEVELOPMENT builds require additional libraries (available from Support) that contain diagnostics that will affect performance. Optional.

buildType = PRODUCTION

Transaction configuration object. Optional.

DataTransport configuration object. Optional

Associative array of NodeType configuration objects keyed by node-type-name. Optional, with no default.

For example, a nodeType named nodetype1 containing the following objects.

Enumeration. The data distribution policy type. Valid values are DYNAMIC or STATIC. Optional. Default value is DYNAMIC.

For example:

type = DYNAMIC

String. Custom quorum notifier names associated with the data distribution policy. The custom quorum notifier name must be defined in a FragmentDefinition configuration in the application. Optional. No default.

For example:

customQuorumNotifiers = ["quorumNotifier", "anotherQuorumNotifier"]

String. Data mapper names associated with the data distribution policy. Data mapper name must be defined in a FragmentDefinition configuration in the application (see FragmentDefinition for more information). Optional. No default.

Enumeration. Valid values are LEAVE_CLUSTER or LEAVE_CLUSTER_FORCE.

Actions performed when a node leaves this group. LEAVE_CLUSTER means the node performs any object migrations needed to migrate partitions owned by this node to the first order replica node, and removes this node from all replica lists.

Before the disable is executed, an audit is done to insure that no partitions will be moved to the UNAVAILABLE state. LEAVE_CLUSTER_FORCE works exactly as above, but no audit step is performed. Optional. The default value is LEAVE_CLUSTER_FORCE.

For example:

disableAction = LEAVE_CLUSTER_FORCE

Enumeration. Actions performed when a node joins this group. Valid values are JOIN_CLUSTER, JOIN_CLUSTER_PURGE, or JOIN_CLUSTER_RESTORE.

JOIN_CLUSTER means the node performs any object migrations needed to activate the partitions defined for this group. Use this option for newly added nodes.

JOIN_CLUSTER_PURGE means before migrating the partition data to the joining node, the node removes any instances that exist on the local node. Use this option for nodes where the local data does not need to be preserved.

JOIN_CLUSTER_RESTORE means for all partitions where the node joining the cluster is the current active node, the node accesses the remote node where the partition should be restored from, and compares the objects between the local node and the remote node. If an object on the local node was updated, or a new object created, the update is pushed to the remote node. If the remote node was updated, the change is copied to the local node. If a state conflict is detected, or a duplicate object is found, remove the local object and copy the remote node object to the local node. For all partitions where the node joining the cluster is acting as a replica, the replica objects are deleted and instances migrated from the remote node.

Optional. The default value is JOIN_CLUSTER.

For example:

enableAction = JOIN_CLUSTER

Bool. Determine how objects are replicated during the migration of an object partition. When set to true, a copy of partitioned objects to all preexisting replica nodes is done. By default, objects are only copied to new replicas as they are added to the cluster since the objects should already exist on the existing replica nodes.

The default behavior allows replica nodes to be incrementally added to a cluster without having to copy the objects to the existing replica nodes. However, if one or more replicas nodes were offline, or were not discovered when the high-availability group was first enabled, this property can be set to insure that objects are pushed to all replicas in the cluster.

Optional. Default value is false.

For example:

forceReplication = false

Long. Define the number of threads used when performing a migration. When migration occurs, the work is done in multiple threads in order to scale to the number of CPUs available in the machine. If the number of partitioned objects is less than the value of objectsLockedPerTransaction, only one thread is used. If objectsLockedPerTransaction is zero, or the calling transaction has one or more partitioned objects locked in the transaction, numberOfThreads is ignored, and all work is done in the caller's transaction. Optional. The default value is 1.

For example:

numberOfThreads = 1

Long. Define the number of objects locked in a transaction when performing a partition migrate or update. When a partition is migrating or being updated the work is done in object chunks defined by this value. This allows applications to concurrently run while the work is in progress, otherwise all partitioned objects would be locked in the transaction performing the work, conflicting with application code also attempting to write lock on the active node or establishing a read lock on replica nodes.

If this value is set to zero, all instances will be processed in the work initiator's transaction. If the calling transaction has one or more partitioned objects locked in the transaction, the objectsLockedPerTransaction value is ignored, and all work is done in the caller's transaction. To ensure that migration or update work minimizes the number of locks taken, it should be run in separate transactions that have no partitioned objects locked. Optional. The default value is 1000.

For example:

objectsLockedPerTransaction = 1000

Enumeration. Valid values are ENABLE_PARTITION or LEAVE_DISABLED.

When a remote node enables a partition, it enables the partition on all nodes in the node list, and updates the partition status and state. This is done even on nodes that have explicitly disabled the partition. This behavior can be changed by setting this value to LEAVE_DISABLED. Note that this only controls the behavior on the local node; it does not affect partitions defined on remote nodes. Optional. The default value is ENABLE_PARTITION.

For example:

remoteEnableAction = ENABLE_PARTITION

Static data distribution policy configuration. Can only be specified if data distribution policy type is STATIC. Optional.

Dynamic data distribution policy configuration. Can only be specified if data distribution policy type is DYNAMIC. Optional.

Bool. If set to true, the mapper installation should be deferred until the type exists in shared memory. Default is false.

This mapper applies to statically or dynamically partitioned classes, and will distribute managed objects across all partitions in the contained availability zone in a round robin fashion.

Defines partitioned classes that should use a distributed hash partitioning policy, and can be any valid string. You can specify a distributedHashDataMapper for both static and dynamic data distribution policies.

Defines an array of partitioned classes in a custom partition mapper, and can be any valid string. You can specify a custom data mapper only with a static data distribution policy.

Router class name. This property is required and has no default value.

For example, for a router named myHashRouter, a className of:

className = "com.tibco.haservice.sample.HashRouter"

Quorum notifier Java class, which is called when the runtime detects the loss of quorum.

For example:

customQuorumNotifiers = {
  quorumNotifier = {
    notifierClassName = "com.tibco.ep.dtm.configuration.node.MyQuorumNotifier"
  }
  anotherQuorumNotifier = {
    notifierClassName = "com.tibco.ep.dtm.configuration.node.AnotherQuorumNotifier"
}