# Stash Latest (2.12) : Stash config properties

Created and last modified by pwatson on Feb 25, 2014

This page describes Stash system properties that can be used to control aspects of the behaviour in Stash. System properties are contained in the `stash-config.properties` file, in your Stash home directory.

Stash must be restarted for changes to become effective.

Default values for system values, where applicable, are specified in the tables below.

On this page:

## Audit

Property | Description
--- | ---
    audit.highest.priority.to.log=HIGH
| Defines the lowest priority audit events that will be logged. Accepted values are: HIGH, MEDIUM, LOW and NONE. Setting the value to HIGH will result in only HIGH level events being logged. NONE will cause no events to be logged. MEDIUM will only allow events with a priority of MEDIUM and HIGH to be logged. Refer to the levels for the various events. This does not affect events displayed in the Audit log screens for projects and repositories.
    audit.details.max.length=1024
| Defines the number of characters that can be can stored as details for a single audit entry.
    plugin.stash-audit.max.entity.rows=500
| The maximum number of entries a project or repository can have in the audit tables. This does not affect the data stored in the logs.
    plugin.stash-audit.cleanup.batch.size=1000
| When trimming the audit entries table this is the maximum number of rows that will be trimmed in one transaction. Reduce this size if you are having issues with long running transactions. This does not affect the data stored in the logs.
    plugin.stash-audit.cleanup.run.interval=24
| How often the audit tables will be checked to see if they need to be trimmed (in hours). This does not affect the data stored in the logs.

## Authentication

Property | Description
--- | ---
`plugin.auth-crowd.sso.enabled=false` | Whether SSO support should be enabled or not. Regardless of this setting SSO authentication will only be activated when a Crowd directory is configured in Stash that is configured for SSO.
`plugin.auth-crowd.sso.session.validationinterval=3` | The number of minutes to cache authentication validation in the session. If this value is set to 0, each HTTP request will be authenticated with the Crowd server.
`plugin.auth-crowd.sso.session.lastvalidation=atl.crowd.sso.lastvalidation` | The session key to use when storing a Date value of the user's last authentication.
`plugin.auth-crowd.sso.session.tokenkey=atl.crowd.sso.tokenkey` | The session key to use when storing a String value of the user's authentication token.

## Avatars

Property | Description
--- | ---
`avatar.gravatar.default=mm` | The fallback URL for Gravatar avatars when a user does not have an acceptable avatar configured. This may be a URL resource, or a Gravatar provided default set. This configuration setting is DEPRECATED. It will be removed in Stash 3.0. Use `avatar.url.default` instead.
`avatar.max.dimension=1024` | Controls the max height and width for an avatar image. Even if the avatar is within the acceptable file size, if its dimensions exceed this value for height or width, it will be rejected. When an avatar is loaded by the server for processing, images with large dimensions may expand from as small as a few kilobytes on disk to consume a substantially larger amount of memory, depending on how well the image data was compressed. Increasing this limit can substantially increase the amount of heap used while processing avatars and may result in OutOfMemoryErrors. Value is in PIXELS.
`avatar.max.size=1048576` | Controls how large an avatar is allowed to be. Avatars larger than this are rejected and cannot be uploaded to the server, to prevent excessive disk usage. Value is in BYTES.
`avatar.temporary.cleanup.interval=1800000` | Controls how frequently temporary avatars are cleaned up. Any temporary avatars that have been uploaded are checked against their configured max age and removed from the file system if they are "too old". Value is in MILLISECONDS.
`avatar.temporary.max.age=30` | Controls how long a temporary avatar that has been uploaded is retained before it is automatically deleted. Value is in MINUTES.
`avatar.url.default=${avatar.gravatar.default}` | Defines the fallback URL to be formatted into the `avatar.url.format.http` or `avatar.url.format.https` URL format for use when a user does not have an acceptable avatar configured. This value may be a URL or, if using Gravatar, it may be the identifier for one of Gravatar's default avatars. The default here falls back on the now-deprecated `avatar.gravatar.default` setting, which should ensure that value, if set, continues to work until it is removed in Stash 3.0. At that time, this default will become "mm".
`avatar.url.format.http=http://www.gravatar.com/` avatar/%1$s.jpg?s=%2$d&d=%3$s | Defines the default URL format for retrieving user avatars over HTTP. This default uses any G-rated avatar provided by the Gravatar service [http://www.gravatar.com] The following format parameters are available: `%1$s` – The user's e-mail address, MD5 hashed, or "00000000000000000000000000000000" if the user has no e-mail `%2$d` – The requested avatar size `%3$s` – The fallback URL, URL-encoded, which may be defined using "avatar.url.default" `%4$s` – The user's e-mail address, not hashed, or an empty string if the user has no e-mail.
`avatar.url.format.https=https://secure.gravatar.com/` avatar/%1$s.jpg?s=%2$d&d=%3$s | Defines the default URL format for retrieving user avatars over HTTPS. This default uses any G-rated avatar provided by the Gravatar service [http://www.gravatar.com] The following format parameters are available: `%1$s` – The user's e-mail address, MD5 hashed, or "00000000000000000000000000000000" if the user has no e-mail `%2$d` – The requested avatar size `%3$s` – The fallback URL, URL-encoded, which may be defined using "avatar.url.default" `%4$s` – The user's e-mail address, not hashed, or an empty string if the user has no e-mail.

## Changesets

Property | Description
--- | ---
`changeset.diff.context=10` | Defines the number of context lines to include around diff segments in changeset diffs.

## Changeset indexing

These properties control how changesets are indexed when new commits are pushed to Stash.

Property | Description
--- | ---
indexing.max.threads=2 | Controls the maximum number of threads which are used to perform indexing. The resource limits configured below are not applied to these threads, so using a high number may negatively impact server performance.
indexing.job.batch.size=250 | Defines the number of changesets which will be indexed in a single database transaction.
indexing.job.queue.size=150 | Defines the maximum number of pending indexing requests. When this limit is reached, attempts to queue another indexing operation will be rejected.
indexing.process.timeout.execution=3600 | Controls how long indexing processes are allowed to execute before they are interrupted, even if they are producing output or consuming input. The value is in SECONDS

## Commit graph cache

Property | Description
--- | ---
`commit.graph.cache.min.free.space=1073741824` | Controls how much space needs to be available on disk (specifically under <STASH-HOME>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk. Value is in BYTES.
`commit.graph.cache.max.threads=2` | Defines the number of threads that will be used to create commit graph cache entries.
`commit.graph.cache.max.job.queue=1000` | Defines the maximum number of pending cache creation jobs.

## Database

Database properties allow very specific configuration for your database connection parameters, which are set by Stash during database setup and migration, and allow you to configure a database of your own. We don't expect that you will edit these, except in collaboration with Atlassian Support.

Any other driver must be placed in `WEB-INF/lib` in order to use the associated database.
Warning:`jdbc.driver` and `jdbc.url` are available to plugins via the ApplicationPropertiesService. Some JDBC drivers allow the username and password to be defined in the URL. Because that property is available throughout the system (and will be included in STP support requests), that approach should not be used. The `jdbc.username` and `jdbc.password` properties should be used for these values instead.

If none of the values below are specified in `stash-config.properties`, then a provided HSQL database will be used.

Property | Description
--- | ---
`jdbc.driver=org.hsqldb.jdbcDriver` | The JDBC driver class that should be used by Stash to connect to the database. The default Stash database uses the file-based HSQL database (`org.hsqldb.jdbcDriver`), storing its data in the `<Stash home directory>`. Stash currently bundles these other JDBC drivers: `org.postgresql.Driver` (more info) `com.microsoft.sqlserver.jdbc.SQLServerDriver` (more info) `oracle.jdbc.driver.OracleDriver` (more info) Icon The JDBC drivers for MySQL are not bundled with Stash (due to licensing restrictions) so you will need to download and install the driver yourself. See this page for directions on installing the driver: Connecting Stash to MySQL
`jdbc.url=jdbc:hsqldb:${stash.home}/data/db;shutdown=true` | This is the JDBC url that Stash will use to connect to the database. This should include the driver subprotocol (e.g., `postgresql:`), the hostname, port and database that you will connect to. This string may vary depending on the database you are connecting to. Please seek specific examples for other databases from your database provider.
`jdbc.user=SA` | This is the user that Stash will connect to the database with. The user will need to be able to create and drop tables and indexes, as well as read and write operations on the entire database schema defined in `jdbc.url`.
`jdbc.password=` | The password that the user defined by `jdbc.user` will connect with.
`jdbc.ignoreunsupported=false` | Allows using a given database, even though it is marked as UNSUPPORTED. This is not intended to be broadly documented, nor to be used generally. It is here as a support mechanism to override the supported database check in the event that it incorrectly blocks access to a database.

## Database pool

These properties control the database pool. The pool implementation used is BoneCP. Documentation for these settings can be found at: http://jolbox.com/configuration.html
To get a feel for how these settings really work in practice, the most relevant classes in BoneCP are:

- com.jolbox.bonecp.BoneCP - Creates the partitions, opens initial connections, starts threads
- com.jolbox.bonecp.BoneCPDataSource - Manages the pool, bridge to the DataSource interface
- com.jolbox.bonecp.PoolWatchThread - Handles the connection threshold

Property | Description
--- | ---
`db.pool.acquireIncrement=2` | Defines the number of connections to open in a batch when open connections are almost exhausted for a given partition.
`db.pool.cache.statements=100` | Defines the number of statements to cache. If you configure your JDBC driver to use loadbalancing or failover with the Stash server, you may need to set `db.pool.cache.statements=0.` Please note that Stash does not yet (as of version 2.8) support DB redundancy, and that this configuration change is not supported by Atlassian.
`db.pool.connection.timeout=15` | 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. Value is in SECONDS.
`db.pool.idle.maxAge=30` | Defines the maximum period of time a connection may be idle before it is closed. Generous values should be used here to prevent creating and destroying many short-lived database connections (which defeats the purpose of pooling). Value is in MINUTES.
`db.pool.idle.testInterval=10` | Defines the amount of time a connection may be idle before a test query is executed by the pool. This helps prevent connections from being closed by the database server due to inactivity. Value is in MINUTES.
`db.pool.partition.connection.maximum=20` | Defines the maximum number of connections that may be open in a given partition.
`db.pool.partition.connection.minimum=4` | Defines the minimum number of connections open for a given partition. Each partition will open this many connections on startup. That means `db.pool.partition.connection.minimum` x`db.pool.partition.count` = initial connection count.
`db.pool.partition.connection.threshold=10` | Defines the threshold as a percentage of the maximum connections that each partition will attempt to keep available at all times. If the number of available connections drops to or below the threshold, `acquireIncrement` connections will be opened until the partition is above it again. Warning: Be careful to take this number into account when setting the minimum and maximum counts. For example, if the maximum is 30 and the minimum is 5 and the threshold is 20 (20%), 5 is not 20% of 30, so immediately after it is created the partition will open additional connections to get above the threshold. Effectively, that would mean that the "minimum" per partition is 10 (5 + 5 `acquireIncrement`), or 40 connections at all times.
`db.pool.partition.count=4` | Defines the number of different connection partitions to use. This value is used to decrease lock contention, because each partition locks individually. The recommended setting is 3 or 4, but in servers with heavy load and many short- lived requests, performance may be improved by using a higher value.
`db.pool.threads=4` | Defines the number of helper threads which will be used by the pool to cleanup and release connections back into the pool. Setting a value of 0 disables this feature, which means the executing thread will perform cleanup and release itself. A non-zero value results in a pool of helpers which process connections out of a holding queue. When a thread "closes" a connection, that thread is allowed to continue executing and the connection is placed in the queue. One of the helper threads then performs final cleanup to prepare the connection to be returned to the pool.

## Downloads

Property | Description
--- | ---
`http.download.raw.policy=Smart` | Controls the download policy for raw content. Possible values are: `Insecure` – Allows all file types to be viewed in the browser `Secure` – Requires all file types to be downloaded rather than viewed in the browser `Smart` – Forces "dangerous" file types to be downloaded, rather than allowing them to be viewed in the browser These options are case-sensitive and defined in `com.atlassian.http.mime.DownloadPolicy`

## Events

These properties control the number of threads that are used for dispatching asynchronous events. Setting this number too high can decrease overall throughput when the system is under high load because of the additional overhead of context switching. Configuring too few threads for event dispatching can lead to events being queued up, thereby reducing throughput. These defaults scale the number of dispatcher threads with the number of available cpu cores.

Property | Description
--- | ---
`event.dispatcher.core.threads=0.8*cpu` | The minimum number of threads that is available to the event dispatcher. The `cpu` variable is resolved to the number of cpus that are available.
`event.dispatcher.max.threads=cpu` | The maximum number of event dispatcher threads. The number of dispatcher threads will only be increased when the event queue is full and max.threads has not been reached yet.
`event.dispatcher.queue.size=4096` | The number of events that can be queued. When the queue is full and no more threads can be created to handle the events, events will be discarded.
`event.dispatcher.keepAlive=60` | The time a dispatcher thread will be kept alive when the queue is empty and more than core.threads threads are running. Value is in SECONDS.

## Executor

Controls the thread pool that is made available to plugins for asynchronous processing.

Property | Description
--- | ---
`executor.max.threads=100` | Specifies the maximum number of threads in the thread pool. When more threads are required than the configured maximum, the thread attempting to schedule an asynchronous task to be executed will block until a thread in the pool becomes available.
`executor.keepAliveTime=60` | Controls how long idle threads are kept alive. Threads idle for more than this time will be terminated. Value is in SECONDS and must be >= 1. If 0 or a negative value is used, a default value of 1 will be configured.

## Features

Feature properties control high-level system features, allowing them to be disabled for the entire instance. Features that are disabled at this level are disabled completely. This means that instance-level configuration for a feature is overridden. It also means that a user's permissions are irrelevant; a feature is still disabled even if the user has the SYS_ADMIN permission.

Property | Description
--- | ---
`feature.auth.captcha=true` | Controls whether to require CAPTCHA verification when the number of failed logins is exceeded. If enabled, any client who has exceeded the number of failed logins allowed using either the Stash web interface or the Git hosting interface will be required to authenticate in the Stash web interface and successfully submit a CAPTCHA before continuing. Setting this to false will remove this restriction and allow users to incorrectly authenticate as many times as they like without penalty. Warning: It is STRONGLY recommended you keep this setting enabled. Disabling it will have the following ramifications: Your users may lock themselves out of any underlying user directory service (LDAP, Active Directory etc) because Stash will pass through all authentication requests (regardless of the number of previous failures) to the underlying directory service. For Stash installations where you use Stash for user management or where you use a directory service with no limit on the number of failed logins before locking out users, you will open Stash or the directory service up to brute-force password attacks.
`feature.forks=true` | Controls whether repositories can be forked. This setting supersedes and overrides instance-level configuration. If this is set to false, even repositories which are marked as forkable cannot be forked.
`feature.public.access=true` | Public access to Stash allows unauthenticated users to be granted access to projects and repositories for specific read operations including cloning and browsing repositories. This is normally controlled by project and repository administrators but can be switched off system wide by setting this property to false. This can be useful in highly sensitive environments.

## Hibernate

Property | Description
--- | ---
`hibernate.format_sql=false` | When `hibernate.show_sql` is enabled, this flag controls whether Hibernate will format the output SQL to make it easier to read.
`hibernate.jdbc.batch_size=20` | Controls Hibernate's JDBC batching limit, which is used to make bulk processing more efficient (both for processing and for memory usage).
`hibernate.show_sql=false` | Used to enable Hibernate SQL logging, which may be useful in debugging database issues. This value should generally only be set by developers, not by customers.

## JIRA

Property | Description
--- | ---
`plugin.jira-integration.pullrequest.attribute.changesets.max=100` | Controls the maximum number of changesets to retrieve when retrieving attributes associated with changesets of a pull-request. This value should be between 50 and 1000 as Stash will enforce an lower bound of 50 issues and an upper bound of 1000 issues.
`plugin.jira-integration.remote.page.max.issues=20` | Controls the maximum number of issues to request from JIRA. This value should be between 5 and 50 as Stash will enforce a lower bound of 5 issues and an upper bound of 50 issues.
`plugin.jira-integration.remote.timeout.connection=5000` | The connection timeout duration in milliseconds for requests to JIRA. This timeout occurs if the JIRA server does not answer. e.g. the server has been shut down. This value should be between 2000 and 60000 as Stash will enforce a lower bound of 2000ms and an upper bound of 60000ms. Value is in MILLISECONDS.
`plugin.jira-integration.remote.timeout.socket=10000` | The socket timeout duration in milliseconds for requests to JIRA. This timeout occurs if the connection to JIRA has been stalled or broken. This value should be between 2000 and 60000 as Stash will enforce a lower bound of 2000ms and an upper bound of 60000ms Value is in MILLISECONDS.

## Liquibase

Property | Description
--- | ---
`liquibase.commit.block.size=10000` | The maximum number of changes executed against a particular Liquibase database before a commit operation is performed. Very large values may cause DBMS to use excessive amounts of memory when operating within transaction boundaries. If the value of this property is less than one, then changes will not be committed until the end of the change set.

## Logging

Logging levels for any number of loggers can be set in the `stash-config.properties` file using the following format:

    logging.logger.<name>=<level>

For example, to configure all classes in the com.atlassian.stash package to DEBUG level:

    logging.logger.com.atlassian.stash=DEBUG

To adjust the ROOT logger, you use the special name ROOT (case-sensitive):

    logging.logger.ROOT=INFO

## Notifications

Property | Description
--- | ---
`plugin.stash-notification.mail.max.comment.size=2048` | Controls the maximum allowed size of a single comment in characters (not bytes). Extra characters will be truncated.
`plugin.stash-notification.mail.max.description.size=2048` | Controls the maximum allowed size of a single description in characters (not bytes). Extra characters will be truncated.
`plugin.stash-notification.mentions.enabled=true` | Controls whether mentions are enabled
`plugin.stash-notification.max.mentions=200` | Controls the maximum number of allowed mentions in a single comment

## Paging

These properties control the maximum number of objects which may be returned on a page, regardless of how many were actually requested by the user. For example, if a user requests Integer.MAX_INT branches on a page, their request will be limited to the value set for `page.max.branches`.
This is intended as a safeguard to prevent enormous requests from tying up the server for extended periods of time and then generating responses whose payload is prohibitively large. The defaults configured here represent a sane baseline, but may be overridden by customers if necessary.

Property | Description
--- | ---
`page.max.branches=1000` | Maximum number of branches per page.
`page.max.changes=1000` | Maximum number of changes per page. Unlike other page limits, this is a hard limit; subsequent pages cannot be requested when the number of changes in a changeset exceeds this size.
`page.max.changesets=100` | Maximum number of changesets (commits) per page.
`page.max.diff.lines=10000` | Maximum number of segment lines (of any type, total) which may be returned for a single diff. Unlike other page limits, this is a hard limit; subsequent pages cannot be requested when a diff exceeds this size.
`page.max.directory.children=500` | Maximum number of directory entries which may be returned for a given directory.
`page.max.directory.recursive.children=100000` | Maximum number of file entries which may be returned for a recursive listing of a directory. A relatively high number as this is used by the file finder which needs to load the tree of files upfront.
`page.max.groups=1000` | Maximum number of groups per page.
`page.max.index.results=50` | Maximum number of changesets which may be returned from the index when querying by an indexed attribute. For example, this limits the number of changesets which may be returned when looking up commits against a JIRA issue.
`page.max.projects=1000` | Maximum number of projects per page.
`page.max.repositories=1000` | Maximum number of repositories per page.
`page.max.source.length=5000` | Maximum length for any line returned from a given file when viewing source. This value truncates long lines. There is no mechanism for retrieving the truncated part short of downloading the entire file.
`page.max.source.lines=5000` | Maximum number of lines which may be returned from a given file when viewing source. This value breaks large files into multiple pages.
`page.max.tags=1000` | Maximum number of tags per page.
`page.max.users=1000` | Maximum number of users per page.
`page.scan.pullrequest.activity.size=500` | The size of the page Stash should use when scanning activities.
`page.scan.pullrequest.activity.count=4` | The number of pages of activities Stash should scan before giving up.

## Password reset

Property | Description
--- | ---
`password.reset.validity.period=4320` | Controls how long a password reset token remains valid for. Default period is 72 hours. Value is in MINUTES.

## Process execution

Property | Description
--- | ---
`process.timeout.execution=120` `process.timeout.idle=60` | Controls timeouts for external processes, such as Git and Hg. The idle timeout configures how long the command is allowed to run without producing any output. The execution timeout configures a hard upper limit on how long the command is allowed to run even if it is producing output. Values are in SECONDS. Using 0, or a negative value, disables the timeout completely. USE AT YOUR OWN RISK!

## Pull requests

Property | Description
--- | ---
    plugin.stash-scm-git.pullrequest.merge.
    strategy.KEY.slug=no-ff
| Control the merge strategy for a repository (where `KEY` is the project key and `slug` is the repository slug). Note that the URL for the browse page of a repository is of the following form: http://<stashdomain>/projects/<PROJECTKEY>/repos/<reposlug>/browse Overrides project and global settings. Possible values are: `no-ff` – no fast-forward; the default setting.`` `ff` – allow fast-forward; will merge when necessary. `ff-only` – require fast-forward; will never create merge commits; fail if a merge is required. `squash` – collapse all incoming commits into a single commit directly to the target branch; never create a merge. `squash-ff-only` – collapse all the incoming commits into a single commit directly to the target branch, never creating a merge, but do so only if the source branch is fast-forward.
    plugin.stash-scm-git.pullrequest.merge.
    strategy.KEY=no-ff
| Control the merge strategy for a project (where `KEY` is the project key). Overrides global settings. Is overridden by repository settings. Possible values are listed above.
    plugin.stash-scm-git.pullrequest.merge.
    strategy=no-ff
| Control the merge strategy globally. Is overridden by repository and project settings. Possible values are listed above.
`pullrequest.diff.context=10` | Defines the number of context lines to include around diff segments in pull request diffs. By default, Git only includes 3 lines. The default is 10, to try and include a bit more useful context around changes, until the ability to "expand" the context is implemented.
`pullrequest.rescope.changesets.display=5` | Defines the maximum number of changesets per type (either added or removed) to display in a rescope activity.
`pullrequest.rescope.changesets.max=1000` | Defines the absolute maximum number of changesets that will be evaluated when attempting to determine, for a given rescope activity, which changesets were added to or removed from a pull request. Adjusting this setting can have significant memory footprint impact on the system. It is not recommended to be changed, but the option is provided here to support unique use cases.
`pullrequest.rescope.detail.threads=2` | Defines the maximum number of threads to use for precalculating rescope details. These threads perform the requisite processing to determine the commits added and removed when a pull request is rescoped, where most rescopes do not add or remove any commits. Such "dead" rescopes are deleted during processing. The primary goal is to ensure all details have already been calculated when users try to view a pull request's overview.
`pullrequest.rescope.drift.threads=4` | Defines the maximum number of threads to use when processing comment drift for a pull request during rescope. Higher numbers here do not necessarily mean higher throughput! Performing comment drift will usually force a new merge to be created, which can be very I/O intensive. Having a substantial number of merges running at the same time can significantly reduce the speed of performing comment drift.

## Readme parsing

Property | Description
--- | ---
`plugin.stash-readme.max.size=65536` | Controls the maximum allowed size of a readme file to parse. Value is in BYTES.

## Ref metadata

Property | Description
--- | ---
`ref.metadata.timeout=2` | Controls timeouts for retrieving metadata associated with a collection of refs from all metadata providers collectively. This values is in SECONDS.
`ref.metadata.max.request.count=100` | Controls the maximum number of refs that can be used in a metadata query.

## Resource throttling

These properties define concurrent task limits for the ThrottleService, limiting the number of concurrent Git operations of a given type
that may be run at once. This is intended to help prevent Stash from overwhelming a server machine with running processes. Stash has two settings to control the number of Git processes that are allowed to process in parallel: one for the web UI and one for the 'hosting' operations (pushing and pulling commits, and cloning a repository).

When the limit is reached for the given resource, the request will wait until a currently running request has completed. If no request completes within a configurable timeout, the request will be rejected.

When requests while accessing the Stash UI are rejected, users will see either a 501 error page indicating the server is under load, or a popup indicating part of the current page failed.

When Git client 'hosting' commands (pull/push/clone) are rejected, Stash does a number of things:

- Stash will return an error message to the client which the user will see on the command line: "Stash is currently under heavy load and is not able to service your request. Please wait briefly and try your request again"
- A warning message will be logged for every time a request is rejected due to the resource limits.
- For five minutes after a request is rejected, Stash will display a red banner in the UI to warn that the server is under load.

The hard, machine-level limits these are intended to prevent hitting are very OS- and hardware-dependent, so you may
need to tune them for your instance of Stash. When hyperthreading is enabled for the server CPU, for example, it is likely that the server will allow sufficient concurrent Git operations to completely bury the I/O on the machine. In such cases, we recommend starting off with a less aggressive default on multi-cored machines – the value can be increased later if hosting operations begin to back up. These defaults are finger-in-the-wind guesstimates (which so far have worked well).

Additional resource types may be configured by defining a key with the format `throttle.resource.<resource-name>`.
When adding new types, it is strongly recommended to configure their ticket counts explicitly using this approach.

Property | Description
--- | ---
`throttle.resource.scm-command=25` | Limits the number of operations that support the UI, such as `git diff`, `git blame`, or `git rev-list`, that can run concurrently. This is intended to prevent these SCM commands from competing with the running of push and pull operations.
`throttle.resource.scm-command.timeout=2` | Controls how long threads will wait for SCM commands to complete when the system is already running the maximum number of SCM commands. Value is in SECONDS.
`throttle.resource.scm-hosting=1.5*cpu` | Limits the number of SCM 'hosting' operations, such as `git clone`, `git push` and `git pull` over HTTP or SSH that may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from pinning a server's resources. There is limited support for mathematical expressions; +,-,*,\ and () are supported. You can also use the `cpu` variable which is resolved to the number of cpus that are available.
`throttle.resource.scm-hosting.timeout=300` | 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. Value is in SECONDS.
`throttle.resource.busy.message.timeout=5` | Controls how long a warning banner is displayed in the UI after a request is rejected due to excessive load. Value is in MINUTES. Using 0, or a negative value, disables displaying the banner. This is deprecated and replaced by `server.busy.on.ticket.rejected.within`, It is due to be removed in Stash 3.0.

## SCM – Cache

See Scaling Stash for Continuous Integration performance for more information about using the SCM Cache Plugin for Stash.

Property | Description
--- | ---
    plugin.stash-scm-cache.expiry.check.interval=300
| Controls how frequently expired caches are checked and deleted from disk. Value is in SECONDS.
    plugin.stash-scm-cache.minimum.free.space=1073741824
| Controls how much space needs to be available on disk (specifically under <STASH-HOME>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk. Value is in BYTES.
    plugin.stash-scm-cache.protocols=HTTP,SSH
| Controls which protocols caching is applied to.
    plugin.stash-scm-cache.refs.enabled=false
| Controls whether ref advertisement operations are cached.
    plugin.stash-scm-cache.refs.ttl=60
| Controls how long the caches for ref advertisements 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. Time is in SECONDS.
    plugin.stash-scm-cache.upload-pack.enabled=true
| Controls whether clone operations are cached.
    plugin.stash-scm-cache.upload-pack.ttl=14400
| 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. Time is in SECONDS.

## SCM – Git

Property | Description
--- | ---
`plugin.stash-scm-git.path.executable=git` | Defines the default path to the Git executable. On Windows machines, the .exe suffix will be added to the configured value automatically if it is not present. In general, "git" should be an acceptable default for every platform, here, assuming that it will be available in the runtime user's PATH. With the new path searching performed by DefaultGitBinaryHelper, setting a default value here is unnecessary, as the plugin will quickly discard the value. This is left here purely for documenting how to set an explicit path.
`plugin.stash-scm-git.path.libexec=` | Defines the path to the Git libexec directory (containing the git-core directory). This path is hard-coded into the Git executable and is used for forking processes like git-http-backend. If this value is set, Stash will directly fork out those processes. This eliminates an unnecessary fork (git -> git-http-backend) and may improve scalability.
`plugin.stash-scm-git.backend.http.buffer.size=32768` | Defines the buffer size in bytes which is used when marshaling data between the Git process and the HTTP socket.
`plugin.stash-scm-git.backend.ssh.buffer.size=32768` | Defines the buffer size in bytes which is used when marshaling data between the Git process and the SSH socket.
`plugin.stash-scm-git.backend.timeout.idle=1800` | Defines the idle timeout for push/pull processes, applying a limit to how long the operation is allowed to execute without either producing output or consuming input. The default value is 30 minutes. This value is in SECONDS.
`plugin.stash-scm-git.backend.timeout.execution=86400` | Defines the execution timeout for push/pull processes, applying a hard limit to how long the operation is allowed to run even if it is producing output or reading input. The default value is 1 day. This value is in SECONDS.
`plugin.stash-scm-git.diff.renames=copies` | Defines whether copy and/or rename detection should be performed. By default, both rename and copy detection are performed. Only files modified in the same commit are considered as rename or copy origins, to minimize overhead. The possible settings are: `copy` or `copies` – Applies `--find-copies` `rename` or `renames` – Applies `--find-renames` `off` – Disables rename and copy detection When using `copy` or `copies`, the value may optionally be suffixed with a "+" to use `--find-copies-harder`. This setting should be used with caution, as it can be very expensive. It considers every file in the repository, even files not modified in the same commit, as possible origins for copies. When copy and/or rename detection is enabled `plugin.stash-scm-git.diff.renames.threshold` can be used control the similarity index required for a change to be identified as a copy or rename.
`plugin.stash-scm-git.diff.renames.threshold=50` | Defines the threshold, as a percentage, for a file to be detected as a rename or a copy. This setting is only applied if copy and/or rename detection is enabled. The default threshold applied is 50% similarity (defined in Git itself). Git diff and Git diff-tree do not honor 100 (identical files only) for the threshold. They ignore the threshold and apply the default 50% threshold instead. A configured threshold of 100 will be applied as 99. Similarly, a configured threshold that is 0, or negative, will be applied as 1.
`plugin.stash-scm-git.environment.variablesize=2000` | Defines the maximum number of characters that can be added to a single environment variable. Different operating systems (and even different versions of the same operating system) have different hard limitations they apply to environment variables. This default is intended to be low enough to work on all supported platforms out of the box, but still high enough to be usable. It is configurable in case it proves to be too high on some platform.
`plugin.stash-scm-git.pullrequest.merge.auto.forceadd=false` | Defines whether conflicted files should be added to the index using Git `add --force`, during automatic merges. By default, this behaviour is off – simple Git `add` is "safer". However, when merging across branches with discrepant `.Gitignore` settings, enabling this setting may allow the system to create a conflicted diff (where without it a diff to the common ancestor will be shown instead). Note: This value has no effect on real pull request merges. It is only applied during automatic merges, for producing a pull request's change tree and diff.
`plugin.stash-scm-git.pullrequest.merge.auto.timeout=120` | Defines the maximum amount of time any command used to perform a merge to support the "merge" diff mode is allowed to execute or idle. Because the commands used generally do not produce output, there is no separate idle timeout. This value is in SECONDS.
`plugin.stash-scm-git.pullrequest.merge.real.timeout=300` | Defines the maximum amount of time any command used to merge a pull request is allowed to execute or idle. Because the commands used generally do not produce output, there is no separate idle timeout. This value is in SECONDS.

## Server busy banners

Property | Description
--- | ---
`server.busy.on.ticket.rejected.within=5` | Controls how long a warning banner is displayed in the UI after a request is rejected due to excessive load. Value is in MINUTES. Using 0, or a negative value, disables displaying the banner.
`server.busy.on.queue.time=60` | Controls how long requests need to be queued before they cause a warning banner to appear. Value is in SECONDS. Using 0, or a negative value, disables displaying the banner.

## SMTP

Property | Description
--- | ---
`mail.timeout.connect=60` `mail.timeout.send=60` `mail.test.timeout.connect=30` `mail.test.timeout.send=30` | Controls timeouts for establishing an SMTP connection and sending an e-mail. Shorter timeouts should be applied for when sending test e-mails, as the test occurs in user time. Values are in SECONDS.
`mail.error.pause.log=300` | Controls how frequently logs will go to the standard log file about mail sending errors. All errors are logged to the `atlassian-stash-mail.log` file, but Stash will periodically log a warning to the standard log file if there are errors sending messages. Value is in SECONDS
`mail.error.pause.retry=5` | Controls how long Stash will wait before retrying to send a message if an error occurs. Value is in SECONDS
`mail.threads=1` | Controls the number of threads to use for sending emails. Setting this to a higher value will put greater load on your mail server when Stash generates a lot of emails, but will make Stash clear its internal queue faster.
`mail.max.message.size=1048576` | Controls the maximum allowed size of a single mail message, which is the sum of the subject and body sizes. Value is in BYTES.
`mail.max.queue.size=157286400` | Controls the maximum allowed size for the mail queue (any new message will be rejected if the mail queue reaches that size). Value is in BYTES.

## SSH command execution

Property | Description
--- | ---
`plugin.ssh.command.timeout.idle=86400` | Controls timeouts for all SSH commands, such as those that service Git and hg operations over SSH. The idle timeout configures how long the command is allowed to run without writing any output to the client. For SCM commands, the plugin.*.backend.timeout.idle properties defined above will be applied to the underlying process. The default value is 1 day. The value is in SECONDS.

## Syntax highlighting

See Configuring syntax highlighting for file extensions for more information.

Stash only applies syntax highlighting to source files, not to diffs.

Property | Description
--- | ---
`syntax.highlighter.<language>.executables=exe1,exe2` | Controls the language highlighter used for a given set of hashbang executables. The `<language>` refers to the highlighter key defined by highlight.js.
`syntax.highlighter.<language>.extensions=ext1,ext2` | Controls the language highlighter used for a given set of file extensions. The `<language>` refers to the highlighter key defined by highlight.js.