# This file specifies property settings for the clustered data store to control its behavior. A
# property may be applied to every data store type ("config" and "operational") or can be customized
# differently for each data store type by prefixing the data store type + '.'. For example, specifying
# the "shard-election-timeout-factor" property would be applied to both data stores whereas specifying
# "operational.shard-election-timeout-factor" would only apply to the "operational" data store. Similarly,
# specifying "config.shard-election-timeout-factor" would only apply to the "config" data store.
# Overall flexibility goes even further, as these overrides can also be combined with per-shard specification,
# so that you can also use:
#   <shard-name>.<setting>
#   <datastore-name>.<shard-name>.<setting>
# for example:
#   topology.shard-election-timeout-factor=2             # override both config/operational for topology shard
#   config.topology.shard-election-timeout-factor=5      # override config for topology shard
#   operational.topology.shard-election-timeout-factor=7 # override operational for topology shard
#

# The multiplication factor to be used to determine shard election timeout. The shard election timeout
# is determined by multiplying shardHeartbeatIntervalInMillis with the shardElectionTimeoutFactor.
shard-election-timeout-factor=20

# The interval at which a shard will send a heart beat message to its remote shard.
#shard-heartbeat-interval-in-millis=500

# The amount by which to divide election timeout in case of a candidate. This serves as a counter-balance
# to shard-election-timeout-factor. The default value is 1, i.e. election timeout is the same in all
# situations.
#shard-candidate-election-timeout-divisor=1

# The maximum amount of time to wait for a shard to elect a leader before failing an operation (eg transaction create).
#shard-leader-election-timeout-in-seconds=30

# Enable or disable data persistence.
#persistent=true

# Disable persistence for the operational data store by default.
operational.persistent=false

# The maximum amount of time a shard transaction can be idle without receiving any messages before it self-destructs.
#shard-transaction-idle-timeout-in-minutes=10

# The maximum amount of time a shard transaction three-phase commit can be idle without receiving the
# next messages before it aborts the transaction.
#shard-transaction-commit-timeout-in-seconds=30

# The maximum allowed capacity for each shard's transaction commit queue.
#shard-transaction-commit-queue-capacity=20000

# The maximum amount of time to wait for a shard to initialize from persistence on startup before
# failing an operation (eg transaction create and change listener registration).
#shard-initialization-timeout-in-seconds=300

# The minimum number of entries to be present in the in-memory journal log before a snapshot is to be taken.
#shard-snapshot-batch-count=20000

# The percentage of Runtime.totalMemory() used by the in-memory journal log before a snapshot is to be taken.
# Disabled, if direct threshold is enabled.
#shard-snapshot-data-threshold-percentage=12

# The max size of in-memory journal(in MB), after reaching the limit, snapshot will be taken. Should be not less then 1.
# If set to 0, direct threshold is disabled and percentage is used instead.
#shard-snapshot-data-threshold=0

# The interval at which the leader of the shard will check if its majority followers are active and
# term itself as isolated.
#shard-isolated-leader-check-interval-in-millis=5000

# The number of transaction modification operations (put, merge, delete) to batch before sending to the
# shard transaction actor. Batching improves performance as less modifications messages are sent to the
# actor and thus lessens the chance that the transaction actor's mailbox queue could get full.
#shard-batched-modification-count=1000

# The maximum amount of time for akka operations (remote or local) to complete before failing.
#operation-timeout-in-seconds=5

# Obsolete: this knob will be removed in a future release.
#
# The initial number of transactions per second that are allowed before the data store should begin
# applying back pressure. This number is only used as an initial guidance, subsequently the datastore
# measures the latency for a commit and auto-adjusts the rate limit.
#transaction-creation-initial-rate-limit=100

# A symbolic name for the RaftPolicy implementation to use. An instance with this name should
# be made available as a service. If this property is set to a name that cannot be resolved,
# then the normal RAFT behavior will be used. Symbolic names recognized out of the box are:
# - normal
# - disable-elections
# - two-node-cluster
#custom-raft-policy-implementation=

# When fragmenting messages thru the akka remoting framework, this is the maximum size in bytes
# for a message slice. This needs to be below Akka's maximum-frame-size and defaults to 480KiB.
maximum-message-slice-size=491520

# Tune the maximum number of entries a follower is allowed to lag behind the leader before it is
# considered out-of-sync. This flag may require tuning in face of a large number of small transactions.
#sync-index-threshold=10

# Record new transaction allocation stack trace, useful for debugging.  This makes the log include
# the stack trace of the creator of the Tx when there is an exception when the transaction is submitted
# (e.g. for a failed validation).  Defaults to false due to performance impact.
#transaction-debug-context-enabled=true

# Multiplicator of shard-leader-election-timeout-in-seconds for the purposes of initial datastore
# convergence. Each frontend datastore instance will wait specified amount of time before becoming
# exposed as a service. A value of 0 indicates waiting forever. Defaults to 3.
#initial-settle-timeout-multiplier=3

#Interval after which a snapshot should be taken during the recovery process.
#recovery-snapshot-interval-seconds=0

# Option to take a snapshot when the entire DataTree root or top-level container is overwritten
snapshot-on-root-overwrite=false

# Enable lz4 compression for snapshots sent from leader to followers
#use-lz4-compression=true

# Export snapshot and journal content after recovery, possible modes: off, json
#
# Journal Json structure:
#       Entries : [
#            Entry : [
#                Node: [
#                   Path : {},
#                   ModificationType : {},
#                   Data : {}
#                ]
#            ]
#        ]
#
# Snapshot Json structure:
#       RootNode : {}
#
export-on-recovery=off

# Directory name for export files
#recovery-export-base-dir=persistence-export