authentication.allowed-clock-skew

Defines the clock skew allowed when validation expiry for signed tokens during authentication. This accounts for clock drift between Bitbucket and Mesh nodes. This value is in SECONDS unless a unit (s, m, h, d) is specified.

authentication.expiry-interval

Defines the amount of time a signed token is valid after it's issued. This only affects outbound requests, such as replication requests from one Mesh node to another. Since tokens are generated right before the RPC they will be used to authenticate, this interval should generally be short. This value is in SECONDS unless a unit (s, m, h, d) is specified.

commit.message.max

Controls the maximum length of the commit message to be loaded when retrieving one or more commits. Commit messages longer than this limit will be truncated. The default limit is high enough to not affect processing for the general case, but protects the system from consuming too much memory in exceptional cases.

commit.message.bulk.max

Controls the maximum length of the commit message to be loaded when retrieving commits in bulk. Commit messages longer than this limit will be truncated. The default limit is high enough to not affect processing for the common case, but protects the system from consuming too much memory when many commits have long messages.

database.pool.idle-size

Defines the number of connections the pool tries to keep idle. The system can have more idle connections than the value configured here. As connections are borrowed from the pool, this value is used to control whether the pool will eagerly open new connections to try and keep some number idle, which can help smooth ramp-up for load spikes.

database.pool.max-size

Defines the maximum number of connections the pool can have open at once.

database.pool.connect-timeout

Defines the amount of time the system will wait when attempting to open a new connection before throwing an exception. The system may hang, during startup, for the configured number of seconds if the database is unavailable. As a result, the timeout configured here should not be generous.

If no unit is specified (ms, s, m, h) this value is in seconds.

database.pool.idle-timeout

Defines the maximum period of time a connection may be idle before it is closed. In general, generous values should be used here to prevent creating and destroying many short-lived database connections (which defeats the purpose of pooling).

If no unit is specified (ms, s, m, h) this value is in minutes.

database.pool.leak-timeout

Defines the maximum period of time a connection may be checked out before it is reported as a potential leak. By default, leak detection is not enabled. Long-running tasks can easily exceed this threshold and trigger a false positive detection.

If no unit is specified (ms, s, m, h) this value is in minutes.

database.pool.lifetime-timeout

Defines the maximum lifetime for a connection. Connections which exceed this timeout are closed the first time they become idle and fresh connections are opened.

If no unit is specified (ms, s, m, h) this value is in minutes.

executor.max-threads

Controls the maximum number of threads allowed in the common ExecutorService. This ExecutorService is used by for background tasks. When more threads are required than the configured maximum, the thread attempting to schedule an asynchronous task to be executed will block for up to executor.timeout until a thread in the pool becomes available. By default, the pool size scales with the number of reported CPU cores. Note: A minimum of 4 is enforced for this property. Setting the value to a lower value will result in the default 4 threads being used.

executor.timeout

Controls how long a thread submitting a task to the common ExecutorService should block when all threads in the pool are busy before giving up and rejecting the task.

This value is in seconds.

git.path.executable

Defines the path to the git executable. If no value is set, the system searches the runtime user's PATH and standard system paths to find a suitable git executable.

Setting a value here is usually not necessary. This is left here purely for documenting how to set an explicit path.

hooks.callback.timeout

Controls the maximum time a git hook callback is allowed to execute before being aborted, thereby rejecting the request if the hook can reject the request. When one or more refs are updated and a pre-receive or post-receive request is sent back to the RPC client, this setting controls how long the application will wait for the RPC client to respond.

This value is in seconds.

hookscripts.gc.interval

Defines the number of hours to wait between garbage collection runs for hook scripts.

This unit is in hours. The default is 24 hours (1 day).

hookscripts.gc.prune

Defines the minimum age of a hook script before it can be considered for garbage collection.

This unit is in hours. The default is 1 week.

hosting.allow-filter

Controls whether partial clones, using --filter, are allowed. Partial clones are not cached, and some of the filters offered by Git can be very resource-intensive for the server to apply, so it can sometimes be more efficient to use a normal clone (or a shallow one) instead. Partial clones are enabled by default.

hosting.atomic-initial-push

Controls whether initial pushes are treated as an atomic push by the system. This option is enabled by default because it significantly reduces the overhead of coordinating and replicating the initial push. Only disable this option in case of issues with initial pushes.

hosting.cache.expiry.check.interval

Controls how frequently expired cache entries are invalidated and removed from the cache.

This value is in seconds.

hosting.cache.eviction.hysteresis

When eviction is triggered the amount of disk space requested for eviction is calculated as (eviction.hysteresis + eviction.trigger.free.space - free space under <Mesh home directory>/caches)

This value is in bytes.

hosting.cache.eviction.trigger.free.space

Controls the threshold at which eviction is triggered in terms of free space available on disk (specifically under <Mesh home directory>/caches)

This value is in bytes.

hosting.cache.minimum.free.space

Controls how much space needs to be available on disk (specifically under <Mesh home directory>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk.

This value is in bytes.

hosting.cache.pack.enabled

Controls whether caching is enabled for git-upload-pack (clone operations).

hosting.cache.pack.maxCount

The maximum number of upload-pack cache entries to retain per repository. If there are more than this configured limit, the least recently accessed entry will be invalidated.

hosting.cache.pack.ttl

Controls how long the caches for clone operations are kept around when there no changes to the repository.

Caches are automatically invalidated when someone pushes to a repository or when a pull request is merged.

This value is in seconds.

hosting.cache.protocol.http.enabled

Controls which whether caching over HTTP(S) is enabled.

hosting.cache.protocol.ssh.enabled

Controls which whether caching over SSH(S) is enabled.

metrics.tags.application

Any metrics tags that should be added to all metrics reported from this node can be added as properties under metrics.tags. For instance, if metrics reported by this node should be tagged with region=us-east-1, this node is running under, add metrics.tags.region=us-east-1

management.metrics.export.datadog.enabled

Datadog metrics configuration. Please set enabled=true to enable publishing of metrics to Datadog and uncomment and update the relevant Datadog configuration properties in the section below.

management.metrics.export.dynatrace.enabled

Dynatrace metrics configuration. Please set enabled=true to enable publishing of metrics to Dynatrace and uncomment and update the relevant Dynatrace configuration properties in the section below.

management.metrics.export.influx.enabled

InfluxDB metrics configuration. Please set enabled=true to enable publishing of metrics to InfluxDB and uncomment# and update the relevant InfluxDB configuration properties in the section below.

management.metrics.export.influx.auto-create-db

Whether to create the Influx database if it does not exist before attempting to publish metrics to it. (Default: true)

management.metrics.export.influx.batch-size

Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made. (Default: 10000)

management.metrics.export.influx.batch-size.compressed

Whether to enable GZIP compression of metrics batches published to Influx. (Default: true)

management.metrics.export.influx.batch-size.connect-timeout

Connection timeout for requests to this backend. (Default: 1s)

management.metrics.export.influx.batch-size.consistency

Write consistency for each point. (Default: one)

management.metrics.export.influx.batch-size.db

Tag that will be mapped to "host" when shipping metrics to Influx. (Default: mydb)

management.metrics.export.influx.batch-size.enabled

Whether exporting of metrics to this backend is enabled. (Default: true)

management.metrics.export.influx.batch-size.num-threads

Number of threads to use with the metrics publishing scheduler. (Default: 2)

management.metrics.export.influx.batch-size.password

Login password of the Influx server.

management.metrics.export.influx.batch-size.read-timeout

Read timeout for requests to this backend. (Default: 10s)

management.metrics.export.influx.batch-size.retention-policy

Retention policy to use (Influx writes to the DEFAULT retention policy if one is not specified).

management.metrics.export.influx.batch-size.step

Step size (i.e. reporting frequency) to use. (Default: 1m)

management.metrics.export.influx.batch-size.uri

URI of the Influx server. (Default: http://localhost:8086)

management.metrics.export.influx.batch-size.user-name

Login user of the Influx server.

management.metrics.export.jmx.enabled

Configures whether metrics should be exposed over JMX

management.metrics.export.newrelic.enabled

NewRelic metrics configuration. Please set enabled=true to enable publishing of metrics to NewRelic and uncomment# and update the relevant NewRelic configuration properties in the section below.

management.metrics.export.newrelic.account-id

management.metrics.export.newrelic.api-key

management.metrics.export.newrelic.step

The interval at which metrics are sent to New Relic. See Duration.parse for the expected format. The default is 1 minute.

management.metrics.export.signalfx.enabled

SignalFX metrics configuration. Please set enabled=true to enable publishing of metrics to SignalFX and uncomment# and update the relevant SignalFX configuration properties in the section below.

management.metrics.export.statsd.enabled

StatsD metrics configuration. Please set enabled=true to enable publishing of metrics to StatsD and uncomment# and update the relevant StatsD configuration properties in the section below.

process.timeout.execution

Configures a hard upper limit on how long the command is allowed to run even if it is producing output.

This value is in seconds. Using 0, or a negative value, disables the timeout completely.

process.timeout.idle

The idle timeout configures how long the command is allowed to run without producing any output.

This value is in seconds. Using 0, or a negative value, disables the timeout completely.

profiling.enabled

Controls whether profiling should be enabled or not

profiling.min-frame-time

Defines the threshold time (in milliseconds) below which a profiled event should not be reported.

profiling.min-trace-time

Defines the threshold time (in milliseconds) below which an entire stack of profiled events should not be reported.

profiling.max-frame-name-length

Defines the maximum length of a profiling frame in the profiling log. Setting this value too high can lead to out of memory issues because profiling frames are kept in memory until the request ends. Longer frames will be abbreviated.

repair.backoff.initial-delay

Configures the delay between the first repair failure and the next attempt to repair the replica. This value is in seconds.

repair.backoff.jitter

Configures the fraction of jitter to apply to the next delay to help spread out delays of concurrent repair operations. The default is 5%, which results in the next calculated delay being increased or decreased by up to 2.5%

repair.backoff.max-delay

Configures the maximum delay between two repair attempts. This value is in seconds. The default is 30 minutes.

repair.backoff.multiplier

Configures the factor by which the delay between two repair attempts should be increased The default value is 1.2, for a ~20% increase between attempts (+/- jitter).

repair.max-attempts

Configures the maximum amount of times repair is attempted if the replica does not become consistent after repair completes, or repair fails because no consistent replicas are available to repair from.

repair.throttle.limit

Configures the maximum number of concurrent repair operations

repair.throttle.timeout

Configures a hard upper limit on how long repair will wait for a repair slot to become available

This value is in seconds. Using 0, or a negative value, disables the timeout completely. The default is 30 seconds.

repair.timeout.execution

Configures a hard upper limit on how long repository repair is allowed to run.

This value is in seconds. Using 0, or a negative value, disables the timeout completely. The default is 24 hours.

repair.update-ref.batch-size

Configures the maximum amount of refs to update in a single git update-ref operation as part of repair. If repair needs to update more than the configured limit, multiple git update-ref operations will be used.

replication.quorum-mode

Controls how replica votes are applied when replicating transactions.

Available modes are: - always: If the leader prepares the transaction successfully, it is always committed--even if every other replica votes no. This mode makes write operations more likely to succeed, but may result in more frequent inconsistencies between nodes. - majority: Transactions are only committed if the majority (more than half) of replicas vote yes. Otherwise, the transaction is rolled back. Any replicas that voted no for a transaction that is still committed are marked as inconsistent and scheduled for repair. They will not process requests for the repository until repairs have completed. This mode balances consistency with availability. - unanimous: Transactions are only committed if every replica votes yes. Otherwise, the transaction is rolled back. This mode offers the best consistency, at the expense of making writes more fragile since a single replica failing will trigger a rollback.

The default is to require a majority vote.

storage.temp-cleanup-interval

Determines the interval used for how frequent the clean up of the tmp directory on the Mesh node job is run. The default interval is 1 day specified in hours.

storage.temp-expiry

Determines the interval used to calculate whether a file or directory is stale for it to be deleted on the Mesh node in the tmp directory. The default interval is 3 days specified in hours.

scaling.concurrency

Allows adjusting the scaling factor used. Various other CPU/throttling dependent properties are defined in terms of this setting, so adjusting this value implicitly adjusts those. Some examples:

• event.dispatcher.core.threads

• event.dispatcher.max.threads

• executor.max.threads

• throttle.resource.git-hosting

The default value, cpu, resolves to the number of detected CPU cores. On hyperthreaded machines, this will be double the amount of physical cores.

throttle.resource.git-lfs

Limits the number of Git LFS file transfer operations which may be running concurrently. This is primarily intended to prevent Git LFS requests from consuming all available connections thereby degrading UI and Git hosting operation. This should be a fraction of the maximum number of concurrent connections permitted by Tomcat.

throttle.resource.git-lfs.timeout

Controls how long threads will wait for Git LFS uploads/downloads to complete when the system is already running the maximum number of concurrent transfers. It is recommended this be set to zero (i.e. don't block) or a few seconds at most. Since waiters still hold a connection, a non-zero wait time defeats the purpose of this throttle.

This value is in seconds.

throttle.resource.mirror-hosting

Limits the number of SCM hosting operations served to mirrors, which may be running concurrently. This limit is intended to protect the system's CPU and memory from being consumed excessively by mirror operations.

Note that dynamic throttling is not supported for mirror hosting operations.

throttle.resource.mirror-hosting.timeout

Controls how long threads will wait for mirrors hosting operations to complete when the system is already running the maximum number of git commands.

This value is in seconds.

throttle.resource.scm-command

Limits the number of git commands, such as: git diff, git blame, or git rev-list, which may be running concurrently. This limit is intended to prevent the operations which support the UI from preventing push/pull operations from being run.

throttle.resource.scm-command.timeout

Controls how long threads will wait for SCM commands to complete when the system is already running the maximum number of SCM commands.

This value is in seconds.

throttle.resource.scm-hosting.timeout

Controls how long threads will wait for SCM hosting operations to complete when the system is already running the maximum number of SCM hosting operations.

This value is in seconds.

throttle.resource.scm-hosting.strategy

Specifies the strategy for throttling SCM hosting operations. Possible values are 'adaptive' and 'fixed'.

If 'fixed' is specified, throttle.resource.scm-hosting.fixed.limit is used as the fixed upper limit on the number of concurrent hosting operations.

If 'adaptive' is specified, the maximum number of hosting operations will vary between throttle.resource.scm-hosting.adaptive.min and throttle.resource.scm-hosting.adaptive.max based on how many hosting operations the system believes the machine can support in its current state and given past performance.

If any configured adaptive throttling setting is invalid and reverts to a default but this conflicts with other correctly configured or default settings, the throttling strategy will revert to 'fixed'. E.g. this will occur if throttle.resource.scm-hosting.adaptive.min is set to the same value as throttle.resource.scm-hosting.adaptive.max

throttle.resource.scm-hosting.adaptive.limit.min

When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the lower limit on the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently.

Setting a lower limit provides a way to specify a minimum service level for SCM hosting operations regardless of what the adaptive throttling heuristic believes the machine can handle.

There is limited support for mathematical expressions; +,-,*,/ and () are supported.

throttle.resource.scm-hosting.adaptive.limit.max

When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the upper limit on the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from exhausting a server's resources. Note that if the machine does not have sufficient memory to support this default value or an explicitly configured value, a smaller value will be chosen on startup.

Adaptive throttling will vary the total tickets There is limited support for mathematical expressions; +,-,*,/ and () are supported.

throttle.resource.scm-hosting.adaptive.cpu.target

When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the target CPU utilisation for the machine (across all processors) which the system takes into consideration when calculating the current throttling limit.

This value represents a trade-off: higher numbers may boost raw throughput of hosting operations, but at the expense of overall system responsiveness for all users. Increasing the target too high or too low brings diminishing returns.

This must be a value between 0.0 and 1.0 and is a percentage of the total available CPU power across all cores

throttle.resource.scm-hosting.fixed.limit

When the fixed strategy is enabled for throttling SCM hosting operations, this limits the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from exhausting a server's resources. There is limited support for mathematical expressions; +,-,*,/ and () are supported.

throttle.resource.scm-refs

Limits the number of ref. advertisement operations, which may be running concurrently. Those are throttled separately from clone operations as they are much more lightweight and much shorter so we can and should allow many more of them running concurrently.

throttle.resource.scm-refs.timeout

Controls how long threads will wait for ref. advertisement operations to complete when the system is already running the maximum number of ref. advertisement operations.

This value is in seconds.

grpc.server.address

The address the gRPC services should bind to. The default value binds to all hosts.

grpc.server.port

The port to use for the gRPC services

grpc.server.ssl.cert-chain-path

The location of the file containing the full certificate chain, when SSL/TLS is used. Default is empty, which means SSL is disabled. Setting a value for this property will only have an effect if grpc.server.ssl.private.key.path is also defined.

grpc.server.ssl.private-key-path

The location of the file containing the private key, when SSL/TLS is used. Default is empty, which means SSL is disabled. Setting a value for this property will only have an effect if grpc.server.ssl.chain.path is also defined.