Configuring global Jira settings
Global Jira settings for Assets include configuration for the Assets app itself, rather than object schemes, object types, or even objects. Here you can configure log settings, date and time, Assets reindexing, and so on. Read on for more details on available settings.
On this page:
- Accessing global Jira settings
- Additional Data Center configuration
- Assets index validation properties
Accessing global Jira settings
To access global Jira settings for Assets:
- Go to Administration > Manage apps.
- Look for pages in the Assets section.
General configuration
To open general configuration, select Assets configuration.
| Setting | Description |
|---|---|
| User interaction | |
Attribute default label | The text type attribute to be used as default label for every object type. You can change this on the specific object type configuration too. Note that this affects only for those object types that are created after this setting has changed. |
Attribute default description | The description for the default label attribute. You can change this on the specific object type configuration too. |
Open Object dialog event | Determines if the object dialog should open when a user selects an object link or when the user hovers with the mouse over an object link. This will also apply when you view Assets object fields while you view a Jira issue. |
Default number of objects fetched in custom fields | This indicates the number of objects that Assets will fetch in custom fields for each request. The default value is set to 25. Once the user starts to search any objects on the custom field, more objects matching the search criteria are fetched from server asynchronously. Hence, the default limit of 25 is recommended and should be enough. If you increase this number, it will affect the performance since more objects would then have to be fetched on every request. |
| General configuration | |
Assets Audit Log enabled | If you check this checkbox, it is ensured that all Assets object events are logged to an audit log file. |
Include attribute values in audit log | This checkbox is enabled only if the above "Assets Audit Log enabled" is checked. If checked, this will include all attribute values of an object in the audit log. |
Restore Assets index from file | This will ensure that on start up, Assets index will be restored from a file. This will help decrease the startup time. Assets will perform a consistency check of the file against the database on startup and recreate the index if they mismatch. If you uncheck this, you may experience a slower start up time. However, it could remove the risk of a potential corrupted index file which may cause data inconsistency. By default, this is checked. The file is located at {$JIRA_HOME/caches/assets_indexes} E.g, path of the file on MacOS will be {/var/atlassian/application-data/jira/caches/assets_indexes} |
Store cache on shutdown | This indicates that the Assets index should be persisted to a file on Assets shutdown (e.g, in cases of a plugin upgrade, Jira restart, Assets disable etc). It is recommended that if "Restore Assets index from file" is checked, this property should be switched on too. |
Restrict Assets Cache | This helps to limit the amount of objects allowed to be stored in Assets. This will subsequently limit the memory footprint by allowing only a limited number of objects to reside in the cache. The default and recommended way to use Assets is to not restrict objects in cache. The limit will have negative performance impact. |
Number of objects allowed in cache | This is enabled only if "Restrict Assets Cache" is checked. This property indicates the number of Assets objects that will be be stored in the cache. The recommended way is to not limit objects in cache. |
Maximum File upload size | The maximum file upload size in bytes when uploading files, images, attachments into Assets. |
Assets parallelism | This is number of threads that Assets will spawn to perform parallel tasks, e.g, importing data, re-indexing etc. If this number is set to a lower value, Assets will put less strain on Jira. However, it will come at the cost of a low performance speed. |
Process data sources via temp files during imports | Temporarily store data on disk when using the import modules to reduce memory footprint during import. |
| Use a custom locale for Assets | This is used to indicate if the data stored in Assets should be sorted by a locale other than Jira's default one. Fetching of objects may be slower if this option is switched on. Hence, by default, this is disabled to avoid performance issues. |
| The locale for Assets | This is enabled only if "Use a custom locale for Assets" is checked. This determines the language Assets should use when sorting data. |
Import temp file buffer size | The maximum number of items stored in memory when processing data sources through temp files |
Import temp file alternative directory | Alternative directory for storing temp files on disk during an import if enabled. Restart your instance for changes to this config to take effect. |
Maximum parallel imports | The number of parallel imports that can run across your cluster. Learn how to configure parallel imports |
Jira Service Management portal search text (single) | Placeholder for the Assets field on the Jira Service Desk portals (Single fields) |
Jira Service Management portal search text (multiple) | Placeholder for the Assets field on the Jira Service Desk portals (Multiple fields) |
| Clustered Data Center | |
| Dedicated scheduling and import node | This setting is available only if you have a multi-node Data Center set up. This node will be the dedicated node to execute Assets scheduling tasks, such as Importers, Automation, manual imports etc. Note that, if a node was selected as the dedicated scheduling node and happens to be unavailable at the time of running a scheduled task, then that task will not run. |
| Frequency of updates for the status of an action in progress | |
| Object index replication | |
| Object load retry attempts | The number of attempts to load the object from the database. |
| Object load retry interval (ms) | The interval between object load attempts. |
| Sender queue size | The size of the work queue for replication messages. Restart your instance for changes to this configuration to take effect. |
| Sender threads | The number of threads for batching and sending replication messages. Restart your instance for changes to this configuration to take effect. |
| Maximum batch size | The maximum number of changes that will be batched together into one message. |
| Batching delay (ms) | The delay to wait for changes to arrive before batching and sending from the work queue. |
| Receiver queue size | The size of the queue for receiving replication messages. Restart your instance for changes to this configuration to take effect. |
| Receiver threads | The number of threads reading from the receiver's queue. Restart your instance for changes to this configuration to take effect. |
| Retry queue threads | The number of threads polling the retry queue. Restart your instance for changes to this configuration to take effect. |
| Retry attempts | The number of retry attempts from the retry queue when an object is not ready to be read from the database when the notification is first received. |
| Retry queue interval (ms) | The interval to wait between retrying messages from the retry queue. |
| Dead-letter queue logging interval (ms) | The interval between checking the contents of the dead-letter queue and logging an error if anything was found on the queue. |
Date settings
All dates in Assets use the Jira administrator settings, and can be changed under the following URL:
https://host:port/secure/admin/AdvancedApplicationProperties.jspaLog files
Logs are located in the following directory:
<Jira-shared-home>/logAttachments
Assets attachments are stored accordingly in subfolders named avatars, files, icons, and objects in the following directory:
<Jira_home>/data/attachments/assetsIndexing
To open indexing configuration, select Indexing Assets.
You can select from the following options for indexing:
- Clean re-index
A clean re-index means that all objects will be removed from the index across all nodes, and then will be indexed again. This is recommended if you want to have a fresh state of the index. Once the indexing is in progress, you won't be able to cancel it or search for objects or filter them. - Re-index
A re-index means that all objects will stay in the index during the process, and Assets will index them again. You can search for objects during the process. - Persist Assets index to file
You can manually persist (copy) the index on your disk. This is useful if you have a big Assets environment with a large number of objects and are planning to reinstall the app. With the index on your disk, Assets won't have to recreate it from scratch.
Testing Groovy scripts
To test Groovy scripts, select Assets script console. It gives you a quick and easy way to test Groovy scripts that you want to use in Assets automation or post-functions.
Syncing reports
To open reports syncing configuration, select Assets reports. Here you can set up a cron schedule, which syncs the data in your reports.
Analytics
To open analytics configuration, select Mindville analytics.
Additional Data Center configuration
Configure data retention period for clustermessage table
Configuring the data retention period helps you avoid performance issues that might result from overloading the clustermessage table. If you import large data sets to Assets in a short period of time, the clustermessage table will be filled with information and can cause performance issues.
To configure the data retention period, complete the following steps:
- Go to Administration > System.
- Scroll down to the Advanced section and select Services.
- Under Add Service, under Class, select Build-in services.
- Select Cluster messaging flush service.
- Enter the following information:
- Name - Cluster Messaging Flush Service
- Class - com.atlassian.jira.service.services.cluster.ClusterMessageCleaningService
- Schedule - 0 0 4/12 * * ?
- Select Add Service.
- Enter the following for Retention Period - 2880m
- Select Update.
Configure frequency of updates for the Process results tab
This setting is available only if you have a multi-node Data Center set up.
The progression of imports is shared across your database for the number of executed units of work that you can set in the Assets configuration. A unit of work quantifies the frequency of updates to the database for an operation in progress. We recommend changing this value only if you notice any user experience performance issues.
For example, in the case of a CSV import, a unit of work represents a single row in the CSV file where a row is an Assets object. For the interval of 100 units of work, the status of the import operation will be updated in the database every time 100 new objects are imported.
The default number of units of work is 100. To change this value:
- Go to Administration > Manage apps.
- In the left-side panel, select Assets configuration.
- Select Edit settings.
- In the Data Center section, edit the value of Frequency of updates for the status of an action in progress.
- Select Save.
Assets index validation properties
The following properties control the Assets indexing process.
Default value | Reloads at runtime | Description | Why you might change this |
|---|---|---|---|
Sender queue size: | |||
10000 | No | The | Set this value large enough to ensure saving object isn’t blocked and to keep the queue drained by the threads. If you see that the queue is getting close to its maximum capacity, increasing its size can help reduce the strain on the parts of the system that send data into the queue. Increasing the queue size might require additional JVM memory, depending on its current availability. |
Sender threads: | |||
5 | No | Specifies the number of sender threads polling the This property is used with the Sender queue size ( | If your instance is handling large imports and bulk changes, increasing this value can help process messages faster. This helps to reduce the work queue size quicker. However, setting the value too high will result in smaller batches and negate the effect of delaying and batching updates into a single message. For more details, check the Maximum batch size and Batching delay properties. |
Maximum batch size: | |||
1000 | Yes | Determines the maximum number of object IDs added to You can observe batch sizes in the logs and Java Management Extensions (JMX). For example, in the debug log for
Additionally, the debug logs for
| If all messages consistently reach the current maximum batch size, it means that replication is struggling to keep up. However, we don't recommend setting this value above 1000 because some databases, like Oracle, have update limits. |
Batching delay: | |||
400 ms | Yes | Specifies the delay between when an item becomes available on a work queue and when the queue is processed. This delay allows the queue to populate, optimizing the batch for bulk creates, updates, and deletes. Increasing the delay can create larger batches but also increase the time it takes for updates to appear on other nodes in the cluster. | If you notice that batches are small, you can increase the delay to allow more time for larger batches to form. If batches are nearing the maximum size set in |
Object load retry attempts: | |||
200 | Yes | Specifies the number of attempts to check the database for an object during its creation if the message is processed before the database transaction is completed. This applies to both additions and updates within the object index when rendering the object. | If you receive messages before they exist in the database and they end up in the dead-letter queue (DLQ), you can increase this setting along with the delay set in |
Object load retry interval: | |||
100 ms | Yes | Determines the delay between attempts to load objects for adds and updates in the object index. | Use this property together with c We don’t recommend reducing this value below 100 ms because it’ll increase the database querying load. |
Receiver queue size: | |||
10000 | No | Specifies the maximum size of the work queue for adding messages to be processed on the receiving nodes. The changes are batched into a single | If you allow the queue to fill up for too long, it can block TCP connections from the Atlassian cache, slowing down other operations, such as index replication. On the other hand, if the queue is unbounded, it can consume excessive memory. |
Receiver threads: | |||
5 | No | Specifies the number of threads polling the | If you have enough computing resources available, you can increase this value to enhance the processing of the queue that contains received messages. This will unblock Jira TCP threads quicker. |
Retry queue threads: | |||
2 | No | Specifies the number of threads polling the retry queue in | If your instance handles a high number of failures, consider increasing this value. Failures might happen because the database doesn't update as quickly as the replication process, causing the retry queue to drain slowly. |
Retry attempts: | |||
10 | Yes | Specifies the number of retry attempts from the retry queue. This determines how many times a failed message is placed back onto the retry queue before it’s moved to the dead-letter queue (DLQ). | Increase this value if you think more retry attempts could lead to successful message processing, such as when you expect database delays. |
Retry queue interval: | |||
60000 ms (1 min) | Yes | Specifies the interval between retry attempts for a message after its last retry. A delay ensures there's enough time for the system to catch up with database updates. During each retry attempt, the object index enters a retry cycle according to the values set for the | Use this property together with |
Dead-letter queue (DLQ) logging interval: | |||
300000 ms (5 min) | Yes | Specifies the interval at which the DLQ is checked for items and a warning is logged. If debug logging is enabled on | If you need to see the DLQ changes faster, decrease the interval. |