opendaylight/md-sal/sal-clustering-config/src/main/resources/initial/datastore.cfg

   1 # This file specifies property settings for the clustered data store to control its behavior. A
   2 # property may be applied to every data store type ("config" and "operational") or can be customized
   3 # differently for each data store type by prefixing the data store type + '.'. For example, specifying
   4 # the "shard-election-timeout-factor" property would be applied to both data stores whereas specifying
   5 # "operational.shard-election-timeout-factor" would only apply to the "operational" data store. Similarly,
   6 # specifying "config.shard-election-timeout-factor" would only apply to the "config" data store.
   7
   8 # The multiplication factor to be used to determine shard election timeout. The shard election timeout
   9 # is determined by multiplying shardHeartbeatIntervalInMillis with the shardElectionTimeoutFactor.
  10 shard-election-timeout-factor=20
  11
  12 # The interval at which a shard will send a heart beat message to its remote shard.
  13 #shard-heartbeat-interval-in-millis=500
  14
  15 # The maximum amount of time to wait for a shard to elect a leader before failing an operation (eg transaction create).
  16 #shard-leader-election-timeout-in-seconds=30
  17
  18 # Enable or disable data persistence.
  19 #persistent=true
  20
  21 # Disable persistence for the operational data store by default.
  22 operational.persistent=false
  23
  24 # The maximum amount of time a shard transaction can be idle without receiving any messages before it self-destructs.
  25 #shard-transaction-idle-timeout-in-minutes=10
  26
  27 # The maximum amount of time a shard transaction three-phase commit can be idle without receiving the
  28 # next messages before it aborts the transaction.
  29 #shard-transaction-commit-timeout-in-seconds=30
  30
  31 # The maximum allowed capacity for each shard's transaction commit queue.
  32 #shard-transaction-commit-queue-capacity=20000
  33
  34 # The maximum amount of time to wait for a shard to initialize from persistence on startup before
  35 # failing an operation (eg transaction create and change listener registration).
  36 #shard-initialization-timeout-in-seconds=300
  37
  38 # The minimum number of entries to be present in the in-memory journal log before a snapshot is to be taken.
  39 #shard-snapshot-batch-count=20000
  40
  41 # The percentage of Runtime.totalMemory() used by the in-memory journal log before a snapshot is to be taken.
  42 #shard-snapshot-data-threshold-percentage=12
  43
  44 # The interval at which the leader of the shard will check if its majority followers are active and
  45 # term itself as isolated.
  46 #shard-isolated-leader-check-interval-in-millis=5000
  47
  48 # The number of transaction modification operations (put, merge, delete) to batch before sending to the
  49 # shard transaction actor. Batching improves performance as less modifications messages are sent to the
  50 # actor and thus lessens the chance that the transaction actor's mailbox queue could get full.
  51 #shard-batched-modification-count=1000
  52
  53 # The maximum amount of time for akka operations (remote or local) to complete before failing.
  54 #operation-timeout-in-seconds=5
  55
  56 # The initial number of transactions per second that are allowed before the data store should begin
  57 # applying back pressure. This number is only used as an initial guidance, subsequently the datastore
  58 # measures the latency for a commit and auto-adjusts the rate limit.
  59 #transaction-creation-initial-rate-limit=100
  60
  61 # The maximum thread pool size for each shard's data store data change notification executor.
  62 #max-shard-data-change-executor-pool-size=20
  63
  64 # The maximum queue size for each shard's data store data change notification executor.
  65 #max-shard-data-change-executor-queue-size=1000
  66
  67 # The maximum queue size for each shard's data store data change listener.
  68 #max-shard-data-change-listener-queue-size=1000
  69
  70 # The maximum queue size for each shard's data store executor.
  71 #max-shard-data-store-executor-queue-size=5000
  72
  73 # A fully qualified java class name. The class should implement
  74 # org.opendaylight.controller.cluster.raft.policy.RaftPolicy. This java class should be
  75 # accessible to the distributed data store OSGi module so that it can be dynamically loaded via
  76 # reflection. For now let's assume that these classes to customize raft behaviors should be
  77 # present in the distributed data store module itself. If this property is set to a class which
  78 # cannot be found then the default raft policy will be applied
  79 #custom-raft-policy-implementation=
  80
  81 # The maximum size (in bytes) for snapshot chunks to be sent during sync
  82 #shard-snapshot-chunk-size=20480000