<storage

descriptor

The store descriptor which is used to localize the store to a specific provider.

Usage: Required prior to 3.4, Deprecated in 3.4+
Default: native://.
X DDL Override:
x.apps.<appname>.storage.descriptor

Starting with the 3.4 release, this attribute has been deprecated. Store clustering should now be configured via the <clustering> element instead.

enabled>

Can be set to false to disable the store for this application.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.enabled
Constraints: true | false

<factories>

Configures a state factories for an application. Each state factory defined under this element is registered with the application's underlying engine and store. Registered message factories are used by the store's replication receiver and transaction log for materialize entity instances from factory and type ids received over the wire.

It is not mandatory to configure factories via DDL, they can also be registered programmatically by the application during application initialization.

SINCE 3.4

<factory

name

The state factory's fully qualified name.

Usage: Required
X DDL Override: Not overridable (key)

</factory>

<factories>

<persistenceQuorum>

Sets a store's persistence quorum. The persistence quorum is the minimum number of store members running in a cluster that determines whether persister commits are executed synchronously or not. If the number of members is greater or equal to the quorum, then persistence commits are always performed asynchronously. Otherwise, they are persisted synchronously.

Usage: Optional
Default: 2
X DDL Override:
x.apps.<appname>.storage.persistenceQuorum
Constraints: non negative integer

<maxPersistSyncBacklog>

When set to a value greater than 0 in seconds, the store's persister will be periodically synced to disk. This limits the amount of unsynced data (in time) that hasn't been synced in the event of a JVM failure, which can be useful for low volume applications that are operating above their persistence quorum.

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.storage.maxPersistSyncBacklog
Constraints: non negative integer

<icrQuorum>

Set's a store's ICR quorum. The ICR quorum is the minimum number of store members running in a cluster that determines whether ICR send commits are executed synchronously or not. If the number of members is greater or equal to the quorum, then ICR commits are always performed asynchronously. Otherwise, they are performed ssynchronously.

Usage: Optional
Default: 2
X DDL Override:
x.apps.<appname>.storage.icrQuorum
Constraints: non negative integer

<maxIcrSyncBacklog>

When set to a value greater than 0 in seconds, the store's icr sendder is periodically synced. This limits the amount of unsynced data (in time) that hasn't been synced in the event of a JVM failure, which can be useful for low volume applications that are operating above their icr quorum.

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.storage.maxIcrSyncBacklog
Constraints: non negative integer

<checkpointingType>

Sets the store's checkpoint controller type. A checkpoint controller determines the checkpoint boundaries within a transaction log by incrementing the checkpoint version for log entries. The checkpoint version is used by CDC and Log Compaction algorithms as the boundaries upon which those operations occur.

Usage: Optional
Default: 'Default'
X DDL Override:
x.apps.<appname>.storage.checkpointingType
Constraints: See CheckpointingType

<checkpointThreshold>

Sets the store's checkpoint threshold. The threshold controls the maximum number of entries before a transaction log's checkpoint version is increased, a checkpoint controller keeps track of the number of entries that count towards reaching this threshold.

Usage: Optional
Default: 'Default'
X DDL Override:
x.apps.<appname>.storage.checkpointThreshold
Constraints: positive integer

<checkpointMaxInterval>

Sets the max time interval (in millis) that can occur before triggering a new checkpoint.

Usage: Optional
Default: 'Default'
X DDL Override:
x.apps.<appname>.storage.checkpointMaxInterval
Constraints: positive integer

<detachedMemberInitialization>

SINCE 3.12.5

Sets whether backup member initialization is performed in a detached manner or not. When member initialization is set to detached, then the member initialization executes concurrently with the store operation. Detached member initialization is another name for non-blocking cluster join.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.detachedMemberInitialization
Constraints: true | false

<detachedMemberInitializerCpuAffinityMask>

SINCE 3.12.5

Sets the CPU affinity mask to use for the detached member initializer thread. The affinity string can either be a long that represents a mask of logical cpu or a square bracket enclosed comma separated list enumerating the logical cpus. For example specifying "1" or "[0]" indicate Core 0. "3" or "[0, 1]" would indicate Core 0 or Core 1. Specifying a value of "0" indicates that the thread should be affinitized to the platform's default cpu, and omitting this value indicates that the thread should be affinitized according to the platform's default policy.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.detachedMemberInitializerCpuAffinityMask
Constraints: String

<discoveryDescriptor>

Sets the custom discovery descriptor for the store.

As of version 3.3, this element is replaced by <discoveryDescriptor> under the <clustering> element.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.discoveryDescriptor
Constraints: String

 This element can be use as an altertive value to using the discoveryDescriptor element. Only one of <discovery> or <discoveryDescriptor> may be used to configure store discovery. When

<failOnMultiplePrimaries>

This property has been deprecated and should be set under the clustering element.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.storage.failOnMultiplePrimaries
Constraints: true | false

<clustering

SINCE 3.4

The clustering element, when enabled, is used to configure store clustering which provides the ability for applications' store members to discover one another and form an HA cluster.

enabled>

Can be set to false to disable store clustering.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.storage.clustering.enabled
Constraints: true | false

<storeName>

Sets the name of the store. Applications with the same store name automatically form a cluster. If this configuration parameter is not specified, then the application name is used as the store name

Usage: Optional
Default: The app name
X DDL Override:
x.apps.<appname>.storage.clustering.storeName
Constraints: String

<localIfAddr>

Sets the local network interface to bind to when establishing cluster network connections.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.localIfAddr
Constraints: String

<localPort>

Sets the TCP port to bind to when listening for cluster connections.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.localPort
Constraints: integer

<linkParams>

A comma separate set of key=value pairs that serve as additional configuration parameters for the network connections between the cluster members.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.linkParams
Constraints: String (a comma separated list of key=value pairs)

<linkReaderCpuAffinityMask>

Sets the CPU affinity mask to use for the cluster connection reader thread. Each cluster member uses a single thread to read replication traffic from other cluster members.

The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

For example, specifying "1" or "[0]" indicates Core 0. "3" or "[0, 1]" would indicate Core 0 or Core 1. Specifying a value of "0" indicates that the thread should be affinitized to the platform's default cpu, and omitting this value indicates that the thread should be affinitized according to the platform's default policy for the multiplexer.

See com.neeve.util.UtlThread.setCPUAffinityMask(String) for details.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.linkReaderCpuAffinityMask
Constraints: String

<discoveryDescriptor>

Sets the custom discovery descriptor for the store.

When set, this descriptor is used to load the discovery provider for the store. In most cases, an application will simply want to use the default discovery provider configured for the JVM which is set via the nv.discovery.descriptor property. In such cases this value need not be set, and the store will simply use the default discovery provider returned by DiscoveryCacheFactory.getDefaultCache() .

However, in some cases where discovery within the same JVM must be partitioned, it can be useful to specify a separate discovery provider for the store, and this property facilitates that.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.discoveryDescriptor
Constraints: String

This element can be use as an altertive value to using the discovery element. Only one of <discovery> or <discoveryDescriptor> may be used to configure xvm discovery. When no discovery information is provided, the value set in the environment for nv.discovery.descriptor is used.

<discovery>

Configures the custom discovery descriptor for the store in decomposed form.

The discovery descriptor is composed as <provider>://<address>[:<port>][&prop1=val1][&propN=valN]

This element can be use as an altertive value to using the discoveryDescriptor element. Only one of <discovery> or <discoveryDescriptor> may be used to configure xvm discovery. When no discovery information is provided, the value set in the environment for nv.discovery.descriptor is used.

<provider>

The discovery provider's name which is used to locate the discovery implementation

Usage: Required
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.discovery.provider
Constraints: String

<address>

The discovery provider's address

Usage: Required
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.discovery.address
Constraints: String

<port>

The discovery provider's port

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.discovery.port
Constraints: positive short

<properties>

List the discovery descriptor parameters in key=value pairs:

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.discovery.properties.<propName>
Constraints: non empty

</discovery>

<initWaitTime>

Sets the time, in milliseconds, that the store cluster manager will wait on open for the cluster to stabilize. When a store binding opens its binding to the store, it joins the discovery network to discover other store cluster members. Once discovered, the members need to connect to each other, perform handshakes and elect roles. This parameter governs how long, after the binding has joined the discovery network, does the cluster manager wait for the store cluster to "stabilize"

A longer initWaitTime will cause the store open operation to take at least that amount of time. It will continue to wait for additional instances to be discovered even if one other member is found. initWaitTime should be set high enough to accommodate the maximum amount of time that is reasonable to expect another member to broadcast itself via discover and accept an connection. For example, if the store or its peers is subject to stop the world VM pauses as a result of long garbage collection, the initWaitTime should be set high enough to accommodate this to avoid to members entering the primary role.

Usage: Optional
Default: unset
X DDL Override:
x.apps.<appname>.storage.clustering.initWaitTime
Constraints: integer

<failOnMultiplePrimaries>

Set whether a store cluster manager should fail the store binding on detecting multiple primaries in a cluster. The default policy is to fail on detecting multiple primaries. This means that if multiple primaries are detected, the members detected as primaries will shut down to prevent a "split-brain" situation. If this parameter is set to true, then the members detected as primaries will not establish connectivity with each other and will continue to operate independently as primaries.

This parameter should only be used if the application or messaging layer possess a distributed locking mechanism that will cause one of the two dual primaries to be unable to start messaging when elected as primary (because there is another primary that has acquired the lock). Specifying this parameter as false without such a mechanism can have significant operational impact on the running of the application.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.storage.clustering.failOnMultiplePrimaries
Constraints: true | false

<memberElectionPriority>

When two members connect and neither has already assumed the primary role, then the member with the lower election priority will be elected primary. Configured values of less than 0 are set to 0 and values configured greater than 255 are set to 255. The default election priority (if not configured here in the DDL) is 255. When two members have the same priority either one may assume the primary role.

Usage: Optional
Default: 255
X DDL Override:
x.apps.<appname>.storage.clustering.memberElectionPriority
Constraints: 0-255

SINCE 3.8

<detachedSend

Configures whether or not to send the outbound replication traffic by the engine thread or pass off the send to a detached replicator sender thread.

Offloading the send to a sender thread can increase store throughput and reduce latency (in some complex flows) but requires an extra processor core for the sender thread.

Usage: Optional

enabled>

Can be set to true to enable detached sends for store replication.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.clustering.detachedSend.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.clustering.detachedSend.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override:
x.apps.<appname>.storage.clustering.detachedSend.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.storage.clustering.detachedSend.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.storage.clustering.detachedSend .queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.storage.clustering.detachedSend.queueFeedMaxConcurrency
Constraints: positive integer

</detachedSend>

<detachedDispatch

Configures whether or not to dispatch the inbound replication traffic and events by the replication link reader thread or pass the dispatch off to a detached replicator dispatcher thread.

Offloading the dispatch to a dispatcher thread can increase store throughput but requires an extra processor core for the dispatcher thread.

Usage: Optional

This feature is currently an experimental feature and is not supported for production usage. It is expected to be supported in a future release.

enabled>

Can be set to true to enable detached sends for store replication.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.clustering.detachedDispatch.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.clustering.detachedDispatch.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override:
x.apps.<appname>.storage.clustering.detachedDispatch.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.storage.clustering.detachedDispatch.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.storage.clustering.detachedDispatch .queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.storage.clustering.detachedDispatch.queueFeedMaxConcurrency
Constraints: positive integer

</detachedDispatch>

</clustering>

<persistence

Configures the persister for this store. A persister is responsible for storing the stores transactional updates to disk (or some other recoverable storage medium). Persisters typically serve as a secondary fault tolerance mechanism for clustered applications, but for an application that will only operate standalone this can serve as the primary mechanism for fault tolerance.

Usage: Optional

See Also: StorePersisterDescriptor

class

Can be set to the fully qualified classname of a custom implemenation of a store persister class. If omitted or "native" is specified, then the platform's default persister will be used (recommended)

Usage: Optional
Default: native
X DDL Override:
x.apps.<appname>.storage.persistence.class

enabled>

Can be set to false to disable the persister for this store.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.storage.persistence.enabled
Constraints: true | false

<autoFlushSize>

In the absense of explicit flushes (e.g. flushOnCommit) of written entries, the size at which flush is automatically triggered for queued writes. If not set the platform default (8192) is used.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.storage.persistence.autoFlushSize
Constraints: positive integer

<flushOnCommit>

Whether or not the persister should be flushed on commit. By default a persister buffers writes into an internal buffer and doesn't write to disk until that buffer has filled. Enabling flush on commit will flush the persister regardless of whether the buffer has filled.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.persistence.flushOnCommit
Constraints: true | false

<flushUsingMappedMemory>

Whether flushes to the log file should be performed using a memory mapped file buffer.

Usage: Optional 
Default: false 
X DDL Override:
x.apps.<appname>.storage.persistence.flushUsingMappedMemory 
Constraints: true | false

There are known issues on some platforms such as windows in which using this setting can cause file locking issues. Therefore, enabling this setting should be tested on the target platform being used.

<autoRepair>

Whether or not an attempt will be made to automatically repair non-empty logs by truncating malformed entries at the end of the log that are part of incomplete transactions.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.persistence.autoRepair
Constraints: true | false

<storeRoot>

Specifies the root folder in which the persister's transaction log files are located.

Usage: Optional
Default: ${NVROOT}/rdat
X DDL Override:
x.apps.<appname>.storage.persistence.storeRoot
Constraints: a file path (possibly relative to the working directory.

If the expected value of of NVROOT on your target deployment host is not on the device where you want to place your transaction logs (e.g. slow or small disk), then consider making this a substitutable vlaue such as:

<storeRoot>${myapp.storeRoot}</storeRoot>, so that you can customize its location at runtime appropriate to the environment in which you are launching.

 <shared>

Whether or not the persister is a share. If omitted or false, the application will use shared nothing persistence. If true it indicates that the persister is using the same physical storage between backup and primaries meaning that instances in a backup role will not persist to disk and leave it to the primary. In most cases applications will leave this as false.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.icr.shared
Constraints: true | false

<cdcEnabled>

Whether CDC is enabled on the log.

If CDC is not enabled, then a CDC processor run on a log will not dispatch any events. If CDC is not enabled on a log and then reenabled later, CDC will start from the live log at the time the CDC is enabled. If a compaction occurred while CDC was disabled, then the change events that occurred during that time will be lost; in other words, CDC enablement instructs the compactor to preserve data on disk necessary for performing CDC rather than deleting it on compaction.

CDC enabled is only supported for applications using StateReplication as an HAPolicy.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.persistence.cdcEnabled
Constraints: true | false

<compactionThreshold>

Sets the log compaction threshold.

The log compaction threshold is the size (in megabytes) that triggers a log compaction. The act of compacting a log will compact as many complete checkpoints in the log and switch the live log over to the compacted log. A threshold value of less than or equal to 0 disables live log compaction.

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.storage.persistence.compactionThreshold
Constraints: integer

Log Compaction is currently only applicable to applications using StateReplication as an HAPolicy.

<maxCompactionWindowSize>

The log compaction window is the approximate maximum size (in megabytes) rounded up to the end of the nearest checkpoint that a compact operation uses to determine how many log entries it will hold in memory. The more entries the compactor can hold in memory while performing a compaction, the more efficient the compact operation will be.

Note: The minimum compaction window is a checkpoint. Therefore, if the system is configured such that a checkpooint covers entries that cumulatively exceeds the value of this parameter, then this parameter will not reduce the compaction memory usage; rather, the compactor will load the entire checkpoint into memory when performing the checkpoint operation.

Note: When calculating memory needed by the compaction operation, one should multiply this parameter by a factor of 2: i.e. the memory used by compaction will be twice the memory specified via this parameter.

Usage: Optional
Default: 1024 (1Gb)
X DDL Override:
x.apps.<appname>.storage.persistence.maxCompactionWindowSize
Constraints: integer

Log Compaction is currently only applicable to applications using StateReplication as an HAPolicy.

<logScavengePolicy>

Sets policy used to scavenge logs.

A log with number N is considered a candidate for scavenging when N is less than the live log number and N less than the CDC log number. This parameter specifies how such logs need to be scavenged. Currently, the only recommended value is 'Delete' ... the 'Disabled' policy is currently used by tools to ensure that they don't erroneously delete files still needed for CDC.

Usage: Optional
Default: Delete
X DDL Override:
x.apps.<appname>.storage.persistence.logScavengePolicy
Constraints: Delete|Disabled

The log scavenge policy only make sense for applications using StateReplication as an HAPolicy, as it pertains only to stale transaction logs left over from CDC or Compaction.

The Disabled policy was introduced in the 3.11 release.

<initialLogLength>

Sets the intial file size of persister's transaction log in gigabytes.

Preallocating the transaction log can save costs in growing the file size over time since the operation of growing a log file may actually result in a write of file data + the metadata operation of updating the file size, and may also benefit from allocating contiguous sectors on disk.

Usage: Optional
Default: 1 (1Gb)
X DDL Override:
x.apps.<appname>.storage.persistence.initialLogLength
Constraints: positive float

The log size is specified in Gb. For an initial size of less than 1 Gb, specify a float value. for example a value of .01 would result in a preallocated size of ~10Mb, this can be useful for test environments.

<zeroOutInitial>

Whether the log file should be explictly zeroed out (to force commit all disk pages) if newly created.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.persistence.zeroOutInitial
Constraints: true | false

<pageSize>

Sets the page size for the disk in bytes. The persister will use this as a hint in several areas to optimize its operation.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.storage.persistence.pageSize
Constraints: positive float

<detachedPersist

Configures whether or not persister writes are done by the store commit thread or passed off to a detached persister write thread. Offloading the persist to a persister thread can increase store throughput but requires an extra processor core for the persister thread.

enabled>

Can be set to true to enable detached persister for the persister.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.persistence.detachedPersist.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override: x.apps.<appname>.storage.persistence.detachedPersist.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override: x.apps.<appname>.storage.persistence.detachedPersist.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.storage.persistence.detachedPersist.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.storage.persistence. detachedPersist.queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.storage.persistence.detachedPersist.queueFeedMaxConcurrency
Constraints: positive integer

</detachedPersist>

</persistence>

<icr

role

Configures the inter-cluster replication role.

See ICRRole
for this application instance

Usage: Required
Default: N/A
X DDL Override:
x.apps.<appname>.storage.icr.role
Constraints: Sender | StandaloneReceiver

busDescriptor

Configures the bus descriptor for ICR. ICR uses its own private bus instance created from this descriptor.

This can be instead of specifying the provider, address, and port properties.

Usage: Required
Default: N/A
X DDL Override:
x.apps.<appname>.storage.icr.busDescriptor
Constraints: String

enabled>

Can be set to true to enable inter cluster replication.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.storage.icr.enabled
Constraints: true | false

<bus

Defines and configures the private bus instance used for ICR.

The ICR bus can be configured by either the bus element or the bus descriptor attribute.

It is illegal to use both mechanism.

<provider>

The bus provider name.

Usage: Required
Default: N/A
X DDL Override:
x.apps.<appname>.storage.icr.bus.provider
Constraints: String

<address> 

The bus address.

Usage: Required
Default: N/A
X DDL Override:
x.apps.<appname>.storage.icr.bus.address
Constraints: String

<port>

The bus port for bus providers that accept a port.

Usage: Required
Default: N/A
X DDL Override:
x.apps.<appname>.storage.icr.bus.port
Constraints: short

<properties>

</properties>

List the bus descriptor parameters in key=value pairs e.g.

Usage: Optional
X DDL Override:
x.apps.<appname>.storage.icr.bus.<propname>
Constraints: short

</bus>

 <shared>

Whether or not an ICR Sender is a shared sender. Applications should set this to true when using ICR to a Standalone Receiver, e.g. only the primary instance should send updated to the ICR queue.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.icr.shared
Constraints: true | false

In most cases applications will want to set this to true.

<flushOnCommit>

Whether or not the icr sender should be flushed on commit. Setting this value to true will flush all updates to the underlying message bus on commit. With a value of false the bus may buffer some messages until new updates are sent on subsequent commits.

Usage: Optional
Default: false
X DDL Override: x.apps.<appname>.storage.icr.flushOnCommit
Constraints: true | false

<detachedSend

Configures whether or not ICR sends are done by the store commit thread or passed off to a detached send thread. Offloading the send to a sender thread can increase store throughput but requires an extra processor core for the sender thread. When enabled the properties here configure the multiplexer for the detached send thread.

enabled>

Configures whether or not detached ICR send is enabled.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.storage.icr.detachedSend.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override: x.apps.<appname>.storage .icr. detachedSend. queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override:
x.apps.<appname>.storage.icr.detachedSend.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.storage.icr.detachedSend.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpu AffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.storage.icr. detachedSend. queueDrainerCpuAffinityMask

<queueFeedMax Concurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.storage.icr.detachedSend.queueFeedMaxConcurrency
Constraints: positive integer

</detachedSend>

</icr>

</storage>

<inboundEventMultiplexing

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.inboundEventMultiplexing.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override: x.apps.<appname>.inboundEventMultiplexing.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.inboundEventMultiplexing.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.inboundEventMultiplexing.queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.inboundEventMultiplexing.queueFeedMaxConcurrency
Constraints: positive integer

</inboundEventMultiplexing>

<inboundMessageLogging

Configures inbound message logging for the engine. An inbound message logger logs inbound messages to a transaction log file. Inbound logging does not play a role in HA for the application, but can be useful for auditing purposes.

policy

The inbound message logging policy for the application.

See InboundMessageLoggingPolicy

Usage: Required
Default: "Default"
X DDL Override:
x.apps.<appname>.inboundMessageLogging.policy
Constraints: Default | Off | UseDedicated

failurePolicy

SINCE 3.2
The inbound message logging failure policy for the application.

See InboundMessageLoggingFailurePolicy

Usage: Optiona
Default: StopEngine
X DDL Override:
x.apps.<appname>.inboundMessageLogging.failurePolicy
Constraints: StopEngine| StopLogging

<autoFlushSize>

In the absence of explicit flushes (e.g. flushOnCommit) of written entries, the size at which flush is automatically triggered for queued writes. If not set, the platform default (8192) is used.

Usage: Optional
Default: 8192
X DDL Override: x.apps.<appname>.inboundMessageLogging.autoFlushSize
Constraints: positive integer

<flushOnCommit>

Whether or not the logger should be flushed on commit. By default the logger buffers writes into an internal buffer and doesn't write to disk until that buffer has filled. Enabling flush on commit will flush the logger regardless of whether the buffer has filled.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.inboundMessageLogging.flushOnCommit
Constraints: true | false

<flushUsingMappedMemory>

Whether flushes to the log file should be performed using a memory mapped file buffer.

Usage: Optional 
Default: false 
X DDL Override:
x.apps.<appname>.inboundMessageLogging.flushUsingMappedMemory 
Constraints: true | false

There are known issues on some platforms such as windows in which using this setting can cause file locking issues. Therefore, enabling this setting should be tested on the target platform being used.

<autoRepair>

Whether or not an attempt will be made to automatically repair a non-empty log on open by truncating malformed entries at the end of the log that are part of incomplete transactions.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.inboundMessageLogging.autoRepair
Constraints: true | false

<storeRoot>

Specifies the root folder in which the logger's transaction log files are located.

Usage: Optional
Default: ${NVROOT}/rdat
X DDL Override:
x.apps.<appname>.inboundMessageLogging.storeRoot
Constraints: a file path (possibly relative to the working directory.  

<initialLogLength>

Sets the initial file size of logger's transaction log in gigabytes.

Preallocating the transaction log can save costs in growing the file size over time since the operation of growing a log file may actually results in a write of file data + the metadata operation of updating the file size, and may also benefit from allocating contiguous sectors on disk.

Usage: Optional
Default: 1 (1Gb)
X DDL Override:
x.apps.<appname>.inboundMessageLogging.initialLogLength
Constraints: positive float

<zeroOutInitial>

Whether the log file should be explicitly zeroed out (to force commit all disk pages) if newly created.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.inboundMessageLogging.zeroOutInitial
Constraints: true | false

<pageSize>

Sets the page size for the disk in bytes. The logger will use this as a hint in several areas to optimize its operation.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.inboundMessageLogging.pageSize
Constraints: positive int

<detachedWrite

Configures whether or not logger writes are done by the committing thread or passed off to a detached writer thread. Offloading to a writer thread can increase application throughput but requires an extra processor core for the logger thread.

enabled>

Can be set to true to enable detached logging for the logger.

Usage: Required
Default: false
X DDL Override:
x.apps.<appname>.inboundMessageLogging.detachedWrite.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.inboundMessageLogging.detachedWrite.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy>

X DDL Override: x.apps.<appname>.inboundMessageLogging.detachedWrite.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.inboundMessageLogging.detachedWrite.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override:
x.apps.<appname>.inboundMessageLogging.
detachedWrite.queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.inboundMessageLogging.
detachedWrite.queueFeedMaxConcurrency
Constraints: positive integer

</detachedWrite>

</inboundMessageLogging>

<outboundMessageLogging

Configures outbound message logging for the engine. An inbound message logger logs sent messages to a transaction log file. An outbound message log file does not play a role in HA for the application, but can be useful for auditing purposes.

policy

The outbound message logging policy for the application.

See OutboundMessageLoggingPolicy

Usage: Required
Default: "Default"
X DDL Override:
x.apps.<appname>.outboundMessageLogging.policy
Constraints: Default | Off | UseDedicated

failurePolicy

SINCE 3.2
The outbound message logging failure policy for the application.

See OutboundMessageLoggingFailurePolicy

Usage: Optiona
Default: StopEngine
X DDL Override:
x.apps.<appname>.outboundMessageLogging.failurePolicy
Constraints: StopEngine| StopLogging

<autoFlushSize>

In the absence of explicit flushes (e.g. flushOnCommit) of written entries, the size at which flush is automatically triggered for queued writes. If not set, the platform default (8192) is used.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.outboundMessageLogging.autoFlushSize
Constraints: positive integer

<flushOnCommit>

Whether or not the logger should be flushed on commit. By default the logger buffers writes into an internal buffer and doesn't write to disk until that buffer has filled. Enabling flush on commit will flush the logger regardless of whether the buffer has filled.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.outboundMessageLogging.flushOnCommit
Constraints: true | false

<flushUsingMappedMemory>

Whether flushes to the log file should be performed using a memory mapped file buffer.

Usage: Optional 
Default: false 
X DDL Override:
x.apps.<appname>.outboundMessageLogging.flushUsingMappedMemory 
Constraints: true | false

There are known issues on some platforms such as windows in which using this setting can cause file locking issues. Therefore, enabling this setting should be tested on the target platform being used.

<autoRepair>

Whether or not an attempt will be made to automatically repair a non-empty log on open by truncating malformed entries at the end of the log that are part of incomplete transactions.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.outboundMessageLogging.autoRepair
Constraints: true | false

<storeRoot>

Specifies the root folder in which the logger's transaction log files are located.

Usage: Optional
Default: ${NVROOT}/rdat
X DDL Override: x.apps.<appname>.outboundMessageLogging.storeRoot
Constraints: a file path (possibly relative to the working directory.

<initialLogLength>

Sets the initial file size of logger's transaction log in gigabytes.

Preallocating the transaction log can save costs in growing the file size over time since the operation of growing a log file may actually results in a write of file data + the metadata operation of updating the file size, and may also benefit from allocating contiguous sectors on disk.

Usage: Optional
Default: 1 (1Gb)
X DDL Override:
x.apps.<appname>.outboundMessageLogging.initialLogLength
Constraints: positive float

<zeroOutInitial>

Whether the log file should be explictly zeroed out (to force commit all disk pages) if newly created.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.outboundMessageLogging.zeroOutInitial
Constraints: true | false

<pageSize>

Sets the page size for the disk in bytes. The logger will use this as a hint in several areas to optimize its operation.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.outboundMessageLogging.pageSize
Constraints: positive float

<detachedWrite

Configures whether or not logger writes are done by the committing thread or passed off to a detached writer thread. Offloading to a writer thread can increase application throughput but requires an extra processor core for the logger thread.

enabled>

Can be set to true to enable detached logging for the logger.

Usage: Required
Default: false
X DDL Override:
x.apps.<appname>.outboundMessageLogging.detachedWrite.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.outboundMessageLogging.detachedWrite.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override:
x.apps.<appname>.outboundMessageLogging.detachedWrite.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.outboundMessageLogging.detachedWrite.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override: x.apps.<appname>.outboundMessageLogging.
detachedWrite. queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.outboundMessageLogging.detachedWrite.queueFeedMaxConcurrency
Constraints: positive integer

</detachedWrite>

</outboundMessageLogging>

<perTransactionStatsLogging

Configures per transaction stats binary logging for the engine.

A per transaction stats logger logs per transaction stats to a transaction log when capturePerTransactionStats is enabled for an AEP engine.

Per transaction stats logging is currently classified as an experimental feature

SINCE 3.7

policy

The per transaction stats logging policy for the application.

See PerTransactionStatsLoggingPolicy

Usage: Required
Default: "Default"
X DDL Override:
x.apps.<appname>. perTransactionStatsLogging .policy

Constraints: Default | Off | UseDedicated

failurePolicy

The per transaction stats logging failure policy for the application.

See PerTransactionStatsLoggingFailurePolicy

Usage: Optiona
Default: StopEngine
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.failurePolicy
Constraints: StopEngine| StopLogging

<autoFlushSize>

In the absence of explicit flushes (e.g. flushOnCommit) of written entries, the size at which flush is automatically triggered for queued writes. If not set, the platform default (8192) is used.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.autoFlushSize
Constraints: positive integer

<flushOnCommit>

Whether or not the logger should be flushed on commit. By default the logger buffers writes into an internal buffer and doesn't write to disk until that buffer has filled. Enabling flush on commit will flush the logger regardless of whether the buffer has filled.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.flushOnCommit
Constraints: true | false

<flushUsingMappedMemory>

Whether flushes to the log file should be performed using a memory mapped file buffer.

Usage: Optional 
Default: false 
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.flushUsingMappedMemory 
Constraints: true | false

There are known issues on some platforms such as windows in which using this setting can cause file locking issues. Therefore, enabling this setting should be tested on the target platform being used.

<autoRepair>

Whether or not an attempt will be made to automatically repair a non-empty log on open by truncating malformed entries at the end of the log that are part of incomplete transactions.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.autoRepair
Constraints: true | false

<storeRoot>

Specifies the root folder in which the logger's transaction log files are located.

Usage: Optional
Default: ${NVROOT}/rdat
X DDL Override: x.apps.<appname>.perTransactionStatsLogging.storeRoot
Constraints: a file path (possibly relative to the working directory.

<initialLogLength>

Sets the initial file size of logger's transaction log in gigabytes.

Preallocating the transaction log can save costs in growing the file size over time since the operation of growing a log file may actually results in a write of file data + the metadata operation of updating the file size, and may also benefit from allocating contiguous sectors on disk.

Usage: Optional
Default: 1 (1Gb)
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.initialLogLength
Constraints: positive float

<zeroOutInitial>

Whether the log file should be explictly zeroed out (to force commit all disk pages) if newly created.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.zeroOutInitial
Constraints: true | false

<pageSize>

Sets the page size for the disk in bytes. The logger will use this as a hint in several areas to optimize its operation.

Usage: Optional
Default: 8192
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.pageSize
Constraints: positive float

<detachedWrite

Configures whether or not logger writes are done by the committing thread or passed off to a detached writer thread. Offloading to a writer thread can increase application throughput but requires an extra processor core for the logger thread.

enabled>

Can be set to true to enable detached logging for the logger.

Usage: Required
Default: false
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.detachedWrite.enabled
Constraints: true | false

<queueDepth>

The size of the feeder queue for the event multiplexer. Typically this value should be a power of 2. When not specified, the platform's default value for the multiplexer will be used.

See <queueDepth>

X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.detachedWrite.queueDepth
Constraints: positive integer

<queueOfferStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueOfferStrategy> 

X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.detachedWrite.queueOfferStrategy
Constraints: See QueueOfferStrategy

<queueWaitStrategy>

Controls the offer strategy for threads publishing to the queue. When not specified, the platform's default value for the multiplexer will be used.

See <queueWaitStrategy>  

X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.detachedWrite.queueWaitStrategy
Constraints: See QueueWaitStrategy

<queueDrainerCpuAffinityMask>

Sets the CPU affinity mask to use for the drainer thread. The affinity string can either be a long that represents a mask of logical cpu, or a square bracket enclosed comma separated list enumerating the logical cpus.

See <queueDrainerCpuAffinityMask>   

X DDL Override: x.apps.<appname>.perTransactionStatsLogging.
detachedWrite. queueDrainerCpuAffinityMask

<queueFeedMaxConcurrency>

Sets the maximum number of threads that will feed the multiplexer's queue.

See <queueFeedMaxConcurrency>     

Usage: Optional
Default: 16
X DDL Override:
x.apps.<appname>.perTransactionStatsLogging.
detachedWrite.queueFeedMaxConcurrency

Constraints: positive integer

</detachedWrite>

</ perTransactionStatsLogging >

<startupExpectations

Specifies expectations that must be met on application startup.

Unmet startup expectations will prevent the application from starting, ensuring that operational conditions are met.

Usage: Optional

<role>

Checks the HA Role of the application on startup.

The role of an application is defined by the underlying role of its store. If the application has no store configured, its role will be 'Primary'.

See StoreBindingRoleExpectation  

Usage: Optional
X DDL Override: x.apps.<appname>.startupExpectations.role
Constraints: Primary | Backup | None

<logEmptiness>

Enforces log emptiness expectations at startup.

See LogEmptinessExpectation  

Usage: Optional
Default: None
X DDL Override: x.apps.<appname>.startupExpectations.logEmptiness
Constraints: None | Empty | NotEmpty

</startupExpectations>

<messageHandlingPolicy>

Specifies the application's message handling policy.

It is rare that an application would want to set anything other than 'Normal' for the message handling policy outside of a diagnostic or debug context.

See MessageHandlingPolicy   

Usage: Optional
Default: Normal
X DDL Override: x.apps.<appname>.messageHandlingPolicy
Constraints: Normal | Noop | Discard

<messagingStartFailPolicy>

SINCE 3.7

Specifies an engine's messaging start fail policy.

The messaging start operation establishes the bindings to the various buses that an engine is configured to bind to. This enumeration enumerates the policy that determines the conditions under which a messaging start operation is considered to have failed.

The NeverFail option causes a start operation to be considered successful as long as all bind attempts do not result in permanent exceptions (a permanent exception reported by a bind attempt causes the bind operation to not be retried while a non-permanent exception causes the bind attempt to be periodically retried). In other words, the NeverFail option causes a messaging start operation to be reported as successful as long as at least one bind attempt was successful or failed with a non-permanent exception. 

See MessagingStartFailPolicy   

Usage: Optional
Default: FailIfOneBindingFails
X DDL Override: x.apps.<appname>.messageStartFailPolicy
Constraints: Normal | FailIfOneBindingFails | FailIfAllBindingsFail

The default policy of FailIfOneBindingFails favors prompt failover to a backup instance which may have connectivity to the message bus in question. Applications that run without a backup may want to use a policy of Reconnect.

 Applications that run without a backup and use only a single message bus or can function adequately with one message bus down may want to use a policy of Reconnect.

<messageBusBindingFailPolicy>

SINCE 3.7

Specifies the policy that determines what action an engine takes when a message bus binding fails. 

See MessageBusBindingFailPolicy   

Usage: Optional
Default: FailIfAnyBindingFails
X DDL Override: x.apps.<appname>.messageBusBindingFailPolicy
Constraints: Reconnect | FailIfAnyBindingFails

The default policy of FailIfAnyBindingFails favors prompt failover to a backup instance which may have connectivity to the message bus in question. If the failure is caused by a failure of the messaging provider (rather than a networking failure local to the Primary instance), the backup instance of the application will use the configured messagingStartFailPolicy along with whatever message bus specific initial connection establishment logic is available in the binding.
Applications that run without a backup may want to use a policy of Reconnect.

<replicationPolicy>

Specifies the application's replication policy.

The replication policy controls how messages are replicated to backup members (or disk).

In most cases an application should specify a policy of Pipelined. Specifying the wrong value for this property can compromise recovery and cause message loss or duplication.

See ReplicationPolicy   

Usage: Optional
Default: Pipelined
X DDL Override:
x.apps.<appname>.replicationPolicy
Constraints: Pipelined | Asynchronous

<messageSendPolicy>

Enumerates an application's AepEngine's outbound message send policies.

The message send policy controls at what point during transaction commit processing that application sent messages are transmitted out of the application. 

In most cases, an application should specify a policy of Pipelined. Specifying the wrong value for this property can compromise recovery and cause message loss or duplication.

See MessageSendPolicy   

Usage: Optional
Default: ReplicateBeforeSend
X DDL Override:
x.apps.<appname>.messageSendPolicy
Constraints: ReplicateBeforeSend| SendBeforeReplicate | Noop

<inboundEventAcknowledgementPolicy>

Enumerates an engine's inbound event acknowledgement policy.

The general contract of an AepEngine is that it cannot acknowledge upstream events (such as message events) in a transaction until such as the transaction has been stabilized to the point that in the event of a failure the message will not be lost.

When the engine is not configured with a store this property has no effect and events are acknowledged when the entire transaction is committed (e.g. when downstream acknowledgements are received.)

See InboundEventAcknowledgementPolicy   

Usage: Optional
Default: Default
X DDL Override:
x.apps.<appname>.inboundEventAcknowledgementPolicy
Constraints: Default | OnSendStability | OnStoreStability

<appExceptionHandlingPolicy>

Set an engine's application exception handling policy, using which an engine determines how to handle unchecked exceptions thrown by an application handler.

See AppExceptionHandlingPolicy

Usage: Optional
Default: RollbackAndStop
X DDL Override:
x.apps.<appname>.appExceptionHandlingPolicy
Constraints: RollbackAndStop | QuarantineAndStop | LogExceptionAndContinue

SINCE 3.4

<quarantineChannel>

Set an engine's quarantine channel.

Sets the channel on which quarantined messages are transmitted. It must take the form of channelName@busName

This applies when the application throws an exception and the application exception policy is configured to be 'quarantine and stop' i.e. QuarantineAndStop

Usage: Optional
Default: null
X DDL Override:
x.apps.<appname>.quarantineChannel
Constraints: (.)+@(.)+

SINCE 3.4

<quarantineMessageKey>

Set an engine's quarantine message key.

Used to explicitly set the message key to be associated with outbound quarantine messages. If the key is set using this method, the sending of the quarantine message will bypass the dynamic key resolution machinery. 

Usage: Optional
Default: null
X DDL Override:
x.apps.<appname>.quarantineMessageKey
Constraints: valid channel key

SINCE 3.4

<messageSendExceptionHandlingPolicy>

The policy used by an application's AepEngine to determine how to handle unchecked exceptions thrown on message sends.

Note that policy covers only the send of the message through the underlying bus binding during transaction commit. In particular, It does not cover:

• Exceptions thrown from send calls made by the application during message processing. That policy must be set via the AppExceptionHandlingPolicy.
• Exceptions that result from processing of acknowledgements for guaranteed message traffic from the message bus. That policy must be set via the MessageSendStabilityFailureHandlingPolicy

See MessageSendExceptionHandlingPolicy

Usage: Optional
Default: TreatAsStabilityFailure
X DDL Override:
x.apps.<appname>.messageSendExceptionHandlingPolicy
Constraints: TreatAsStabilityFailure | LogExceptionAndContinue

<messageSendStabilityFailureHandlingPolicy>

The policy used by an application's AepEngine to determine how to handle send stability failure notifications.

Note that policy covers only the send stability failures received from the underlying bus binding. In particular, It does not cover:

• Exceptions thrown from send calls made by the application during message processing. That policy must be set via the AppExceptionHandlingPolicy.
• Exceptions thrown by the underlying bus binding for send calls made during transaction commit. That policy must be set via the MessageSendExceptionHandlingPolicy.

See MessageSendStabilityFailureHandlingPolicy

Usage: Optional
Default: StopEngine
X DDL Override:
x.apps.<appname>.messageSendStabilityFailureHandlingPolicy
Constraints: StopEngine | LogExceptionAndContinue

SINCE 3.12.6

<replicationPolicy>

Specifies the application's replication policy.

In most cases an application should specify a policy of Pipelined. Specifying the wrong value for this property can compromise recovery and cause message loss or duplication.

See ReplicationPolicy   

Usage: Optional
Default: Pipelined
X DDL Override: x.apps.<appname>.replicationHandlingPolicy
Constraints: Pipelined | Asynchronous

<adaptiveCommitBatchCeiling>

Set the application's AepEngine's adaptive commit batch ceiling.

The adaptive commit batch ceiling controls the maximum number of inbound messages to group into a single transaction which can improve throughput.

A value less than or equal to 1 disables adaptive commit.

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.adaptiveCommitBatchCeiling
Constraints: non negative integer

<enableTransactionCommitSuspension>

Sets whether transaction commit suspension is enabled or disabled.

Transaction commit suspension is an experimental feature that allows an application to temporarily suspend commit of a transaction.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableTransactionCommitSuspension
Constraints: true | false

<dispatchTransactionStageEvents>

Sets whether transaction stage events are emitted by the application's AepEngine.

Controls whether or not AepTransactionStageEvent  are emitted by the application's engine. An AepTransactionStageEvent is used to notify an application as the transaction commit executes through its various phases. The various transaction stages are

• Start
• StoreCommitComplete
• SendCommitComplete
• Complete

The transaction stage is present in the dispatched AepTransactionStageEvent. The AepTransactionStageEvent dispatched in the Start stage can be used by an application to suspend the transaction. It is illegal to suspend a transaction in any other stage other than Start.

Transaction stage events are only dispatched on the primary cluster member

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.dispatchTransactionStageEvents
Constraints: true | false

<replicateSolicitedSends>

Sets whether or not to replicate solicited sends to a backup.

This parameter governs whether solicited sends (sends triggered by the processing of inbound messages) performed on clustered State Replication engines will be replicated or not. This setting has no effect on Event Sourced engines or engines that are not clustered.

<replicateUnsolicitedSends>

Set whether to replicate unsolicited sends.

This parameter governs whether unsolicited sends performed on clustered engines will be replicated or not. This setting has no effect on engines that are not clustered. An unsolicited send is a send done outside of a event handler via an AepEngine.send method. Because unsolicited sends aren't part of an engine's transactional message processing, they are not considered to be part of the application's HA state. To treat unsolicited sends as part of an application's HA state, see sequenceUnsolicitedWithSolicitedSends.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.replicateUnsolicitedSends
Constraints: true | false

<sequenceUnsolicitedSends>

Set whether to sequence unsolicited sends.

By default, unsolicited sends are sent with a sequence number of 0. Specifying true in this parameter will cause sequence numbers to also be attached to unsolicited sends.

Usage: Optional
Default: false
X DDL Override:
 x.apps.<appname>.sequenceUnsolicitedSends
Constraints: true | false

<sequenceUnsolicitedWithSolicitedSends>

Set whether to sequence unsolicited sends with solicited sends.

This parameter is applicable for applications performing concurrent solicited and unsolicited sends and want the unsolicited sends to be sequenced. Setting this parameter ensures that unsolicited and solicited sends are sequenced on the wire in the same order in which the sequence numbers were attached to the messages. In effect, this causes an unsolicited send to be injected into the underlying engine's transactional event processing stream promoting it to a transaction event.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.sequenceUnsolicitedWithSolicitedSends
Constraints: true | false

SINCE 3.9

<dispatchSendStabilityEvents>

Set whether or not the engine dispatches AepSendStabilityEvent for unsolicited sends.

When an application that sends messages through the engine from outside of a message handler (an unsolicited send) would like to receive notification when the the send has been stabilized, this setting can be enabled to instruct the engine to dispatch an AepSendStabilityEvent when the engine can provide guarantees that the message will be delivered. This functionality is useful for gateway applications that input messages into the system from an external source.

Usage: Optional 
 Default: false 
 X DDL Override:  
 x.apps.<appname>.dispatchSendStabilityEvents
 Constraints: true | false

<disposeOnSend>

Set whether or not the engine disposes sent messages.

If set, then the AepEngine.sendMessage method will dispose a message after it has been sent. This means that the caller must not hold onto or reference a message beyond the call to the send message method. If unset, then a zero garbage application must call dispose on each sent message to ensure it is returned to its pool.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.disposeOnSend
Constraints: true | false

<clusterHeartbeatInterval>

Sets the cluster heartbeat interval for the application in milliseconds.

When replicating message and state to its cluster peers, the AepEngine piggybacks internal state, such as outbound message acknowledgements and other internal control data. Setting a cluster heartbeat interval can be useful for low throughput applications to keep the backup in closer sync to the primary. The most common use case for setting this would be to reduce the number of in doubt messages outstanding in backup peers to a window.

A value of 0 (default) disables the cluster heartbeat interval

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.clusterHeartbeatInterval
Constraints: non negative integer

<administrative>

Marks the application as an 'administrative' application.

Marking an application as 'administrative' excludes it from being included in latency or throughput optimizations that demand system resources.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.administrative
Constraints: true | false

<stuckAlertEventThreshold>

Sets the threshold, in seconds, after which an AepStuckAlertEvent is dispatched to the application's IAepAsynchronousEventHandler.  

An AepStuckAlertEvent event is intended to alert that the engine's transaction pipeline is "stuck" i.e. there are one or more transaction commits in the pipeline and the event multiplexer thread is not processing any events. For example, the event multiplexer thread could be flow controlled on the replication TCP connection due to an issue in the backup or could be spinning in a loop in the business logic due to a bug in a business logic handler.

See Stuck Engine Alerts for more information

Usage: Optional
Default: 0
X DDL Override:
x.apps.<appname>.stuckAlertEventThreshold
Constraints: non negative integer

<performDuplicateChecking>

Set whether the application's engine should perform duplicate checking.

When duplicate checking is enabled, received messages that are deemed duplicates are discarded by the application's engine. A message is considered to be a duplicate under the following circumstances:

• The message has a sequence number that is greater than 1.
• The sequence number is less than the last received sequence number for the flowId and senderId in the message.
  • A sequence number of 1 is interpreted as a restart of a messaging stream.
  • A value of 0 or less means the message is not sequenced and will ignored for duplicate checks.

Sequence id assignment by an AepEngine

• MessageSender: Is assigned by the AepEngine using the hash code of the engine name.
• MessageFlow: Leaves flow unset as 0 (default). At present it is not recommended for applications to set a flow.
• MessageSequenceNumber: Set for each send from an event handler by incrementing a sequence number or for each unsolicited send (outside of an event handler) when sequenceUnsolicitedSends is true.

SINCE 3.4

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>. performDuplicateChecking
Constraints: boolean

<setOutboundSequenceNumbers>

Disables the setting of sequence numbers on outbound messages.

The setting of sequence numbers in outbound messages comes at a very slight performance penalty that may not be tolerated by ultra low latency applications. This property can be used to switch off the setting of sequence numbers in outbound messages for such performance critical applications. However, note that this effectively disables checking for duplicates for messages sent by such a configured engine by downstream apps.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>. setOutboundSequenceNumbers
Constraints: boolean

<syncInjectedMessages>

Sets whether MessageView.sync() is called during AepEngine.injectMessage.

When using Event Sourcing or inbound message logging injected messages may be replicated and/or persisted to disk. To do so means that the contents of the message must be synced. By doing sync() during the inject call, it can save the engine's processor thread cpu cycles.

SINCE 3.7

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.syncInjectedMessages
Constraints: boolean

<stopOnJVMShutdown>

Sets whether the engine will automatically stop when the JVM shuts down

By default, the AEP engine registers a JVM shutdown hook using which it automatically stops when the JVM shuts down. This property enables this behavior to be disabled. If set to false, the engine will not automatically stop when the JVM shuts down

 SINCE 3.16.20

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.stopOnJVMShutdown
Constraints: boolean

<performMidstreamInitializationValidation>

Set whether the engine checks that initial transactions are not missing during recovery or replication. This parameter is only applicable to event sourced engines.

It is not recommended that you disable this check unless recommended by Neeve Support.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.performMidstreamInitializationValidation
Constraints: true | false
SINCE 3.4

<enableSequenceNumberTrace>

Enables diagnostic trace logging related to message sequencing. Enabling this trace can assist in diagnosing issues related to the loss, duplicate or out of order events. When enabled, trace will be emitted at debug level (TRACE level for SLF4J) to the logger named 'nv.aep.sno'.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableSequenceNumberTrace
Constraints: true | false
SINCE 3.4

<enableEventTrace>

Enables diagnostic trace logging of events received and dispatched by an engine. Enabling this trace is useful in determining the sequence of events processed by the engine. When enabled, trace will be emitted at debug level (TRACE level for SLF4J) to the logger named 'nv.aep.event'.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableEventTrace
Constraints: true | false
SINCE 3.4

<enableTransactionTrace>

Enables diagnostic trace logging related to transactions processed by an engine. Enabling this trace is useful in determining the relative sequencing and timing of transaction commits as the commits are executed by the engine. When enabled, trace will be emitted at debug level (TRACE level for SLF4J) to the logger named 'nv.aep.txn'.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableTransactionTrace
Constraints: true | false
SINCE 3.4

<enableScheduleTrace>

Enable diagnostic trace logging related to schedules (timers) managed by an engine. Enabling this trace is useful for diagnosing issues related to engine timer execution and scheduling. When enabled, trace will be emitted at debug level (TRACE level for SLF4J) to the logger named 'nv.aep.sched'.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableScheduleTrace
Constraints: true | false
SINCE 3.4

<enableAlertTrace>

Enable diagnostic trace logging related to events emitted by the AepEngine that implement IAlertEvent. When enabled, trace will be emitted at warning level (WARN level for SLF4J) to the logger named 'nv.aep.alert'.

The engine may suppress logging of certain alert event types in cases where it makes sense to do so. For example, the AepEngineStoppedEvent implements IAlertEvent, but when this event is dispatched during a clean shutdown (no error message), it isn't deemed an Alert. Applications may disable the engine alert and provide their own IAlertEvent EventHandler for finer grained control over alert logging.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.enableAlertTrace
Constraints: true | false
SINCE 3.11.61

<enableMessageTrace>

Enables diagnostic trace logging for messages as they pass through the engine. Enabling this trace is useful for tracing the contents of messages at different stages of execution within the engine. When enabled, trace will be emitted at debug level (TRACE level for SLF4J) to the logger named 'nv.aep.msg'.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableMessageTrace
Constraints: true | false
SINCE 3.4

<messageTraceInJson>

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.messageTraceInJson
Constraints: true | false
SINCE 3.4

<messageTraceJsonStyle>

Sets the styling for JSON formatted message trace. This parameter is only applicable if message trace in JSON is enabled.

Valid options are:

• Default: Specifies the default Jackson pretty printer that should be used (DefaultPrettyPrinter)
• PrettyPrint: Same as default.
• Minimal: A minimal single line pretty printer.
• SingleLine: A minimal single line pretty printer. Same as minimal, but with a space after the colon between objects field and value separator (e.g. "intField": 1 vs "intField":1)

Usage: Optional
Default: Default
X DDL Override:
x.apps.<appname>.messageTraceJsonStyle
Constraints: Default | PrettyPrint | Minimal | SingleLine
SINCE 3.4

<messageTraceFilterUnsetFields>

Sets whether unset fields are filtered for JSON formatted objects when JSON message tracing is enabled.

Usage: Optional
Default: false
X DDL Override:
 x.apps.<appname>.messageTraceFilterUnsetFields

Constraints: true | false

<messageTraceMetadataDisplayPolicy>

Sets whether metadata, payload or both will be traced when message tracing is enabled.

Valid Options are:

• On:  Specifies that metadata should be displayed along with the message payload.
• Off:  Specifies that only the message payload should be displayed.
• Only: Specifies that only the metadata should be displayed.

Usage: Optional
Default: On
X DDL Override:
x.apps.<appname>.messageTraceMetadataDisplayPolicy
Constraints: On | Off | Only
SINCE 3.4

<maxEnvironmentProviders>

Sets the maximum number of environment providers that can be registered with the engine.

Usage: Optional
Default: 256
X DDL Override:
x.apps.<appname>.maxEnvironmentProviders
Constraints: positive integer.
SINCE 3.4

<enableSendCommitCompleteSequenceAlerts>

Set whether or not to enable out of order send commit completion detection. When enabled, the engine will check that stability events (acknowledgements) from the underlying messaging provider are received in an ordered fashion. If acknowledgements are received out of order, then the engine will dispatch appropriate alerts.

This check can introduce overhead and is useful in situations in which the message bus is expected to return acks in an ordered fashion. A raised alert is not necessarily an indicator of a problem as the engine will ensure that transactions are completed out in order. In general it is not recommended that this property be enabled unless diagnosing an issue where a bus binding appears not to be acknowledging messages.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.enableSendCommitCompleteSequenceAlerts
Constraints: true | false
SINCE 3.4

<captureMessageTypeStats>

Sets whether statistics are additionally recorded on a per message type basis. Collection of message type specific statistics records counts and rates per type as well as message processing time statistics for each message which can be useful in finding particular handlers that have high execution times.

Enabling message type stats introduces a fair amount of overhead. Before running with this in production be sure to gauge its performance impact for your application to determine whether or not the overhead is worth the additional visibility.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.captureMessageTypeStats
Constraints: true | false
SINCE 3.4

<messageTypeStatsLatenciesToCapture>

Property that enables tracking of latency statistics on a per message type ba

Property controlling which latency stats on a per message type basis. This property is specified as a comma separated list of values. 

Valid value include:

• all Indicates that all available per message type latency stats should be collected.
• none Indicates that no message type latency stats should be collected.
• c2o Indicates create to offer latencies should be captured.
• o2p Indicates offer to poll (input queueing time) should be captured.
• mfilt Indicates that time spent in application message filters should be captured.
• mpproc Indicates that time spent in the engine prior to message dispatch should be captured.
• mproc Indicates that the time spent in application message handlers should be captured.

The values 'all' or 'none' may not be combined with other values.

This value only applies when captureMessageTypeStats is true. When not specified the value defaults to all.

Each latency stat results in a fair amount of overhead - Every latency stat results in a large array being created to hold the data points, and for large a number of message types this can add up quickly in terms of putting pressure on the processor cache. Consider testing the performance impact on your application under load with and without per message type stat latencies enabled. Consider also that each enabled statistics is reported in heartbeats which can increase their size significantly.

Usage: Optional
 Default: all
 X DDL Override:
 x.apps.<appname>.messageStatsTypeLatenciesToCapture
Constraints: see above.

SINCE 3.11

<captureTransactionLatencyStats>

Sets whether or not the engine records transaction latency stats.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.captureTransactionLatencyStats
Constraints: true | false
SINCE 3.4

<capturePerTransactionStats>

Sets whether or not the engine records per transaction stats.

Unlike captureTransactionLatencyStats which records histographical latencies, this setting is much more expensive in that it records and emits individual timestamps for operations that occurred in the transaction including store commit timestamps and individual message timestamps.

In most cases the capturing this level of detail is not worth the overhead it incurs, as the histographical latency captured via captureTransactionLatencyStats is usually sufficient for inferring timings within a given sampling interval. However, in cases where it is critical to determine the exact timings of transaction processing to better understand product behavior it can be useful.

If used in production (which is not recommended), applications should undergo stress testing under maximum peak load to determine the impact of enabling collection of per transaction stats.

Per transaction stats collection is currently classified as an experimental feature. It is subject to change without notice.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.capturePerTransactionStats
Constraints: true | false
SINCE 3.7

<captureEventLatencyStats>

Sets whether or not the engine records event latency stats (such as the amount of time of events spent in its input queue).

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.captureEventLatencyStats
Constraints: true | false
SINCE 3.4

<replicateInParallel>

Enables  parallel replication. When parallel replication is enabled, the engine replicates inbound messages to the cluster backups in parallel with the processing of the message by the message handler. This parameter only applies to Event Sourced engines.

This parameter is particularly useful for Event Sourced applications that have higher message processing times because in this case it may be possible to replicate the message prior to completion of the message handler.

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.replicateInParallel
Constraints: true | false
SINCE 3.4

<preserveChannelJoinsOnStop>

Sets whether or not to preserve joined channels when the engine stops normally.

By default, when an engine is stopped without an error bus channels that were 'joined' will be 'left', meaning that any subscriptions or interests created by the message bus will be unsubscribed or unregistered. Setting this value to true causes the engine to preserve channel interest even on a clean shutdown.

Note that this property has no effect for the case where an engine shuts down with an error (e.g. AepEngine.stop(Exception) with a non-null cause. In this case channel joins are left intact allowing a backup to take over.

Note that this behavior can be overridden programmatically on a case by case basis by a handler for AepEngineStoppingEvent by setting AepEngineStoppingEvent.setPreserveChannelJoins(boolean).

Usage: Optional
Default: false
X DDL Override:
x.apps.<appname>.preserveChannelJoinsOnStop
Constraints: true | false

SINCE 3.4

<setSupportMetadata>

Enables setting of support related metadata on inbound and outbound messages.

Support related metadata is not critical to the operation of an engine and is set by the engine in inbound and outbound messages to aid in support and troubleshooting activities via the metadata being persisted in the application's transaction log.

However, this setting of support related metadata information comes at a slight performance penalty (a couple of microseconds) that may not be tolerated by ultra low latency applications. This property can be used to switch off the setting of support related metadata information in inbound and outbound messages for such performance critical applications.

Usage: Optional
Default: true
X DDL Override:
x.apps.<appname>.setSupportMetadata
Constraints: true | false

SINCE 3.5

</app>

<apps>