Sender queue size: com.atlassian.assets.replication.work.queue.size

10000

いいえ

The CacheMessage work queue determines the maximum size for adding messages to be processed on the sending nodes.

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: com.atlassian.assets.replication.sender.threads

5

いいえ

Specifies the number of sender threads polling the CacheMessage work queue and determines the number of instances of CacheMessageWorkQueuePoller. Worker threads batch multiple cache messages into a single replication message.

This property is used with the Sender queue size (com.atlassian.assets.replication.work.queue.size) property to increase the throughput by adding more threads to drain the queue faster.

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.

1000

はい

Determines the maximum number of object IDs added to AssetsBatchReplicationMessage. The value includes both batch updates and batch creations.

You can observe batch sizes in the logs and Java Management Extensions (JMX). For example, in the debug log for io.riada.insight.index.replication.poller.CacheMessageWorkQueuePoller, you might find entries like:

• Took {} ms to batch {} cache messages and send a single replication message with ID {}.

• Creating batch message from {} cache messages.

Additionally, the debug logs for io.riada.insight.index.replication.poller.AssetsBatchReplicationMessageWorkQueuePoller show:

• Processing {} creates for message with ID {}.

• Processing {} deletes for message with ID {}.

• Processing {} updates for message with ID {}.

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.

400ms

はい

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 com.atlassian.assets.replication.batch.size, you might consider decreasing the delay.

Object load retry attempts: com.atlassian.assets.index.object.load.attempts

200

はい

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 com.atlassian.assets.index.object.load.interval to extend the time spent attempting to load objects.

Object load retry interval: com.atlassian.assets.index.object.load.interval

100ms

はい

Determines the delay between attempts to load objects for adds and updates in the object index.

Use this property together with com.atlassian.assets.index.object.load.attempts to adjust the delay between the attempts to load objects from the database.

We don’t recommend reducing this value below 100 ms because it’ll increase the database querying load.

Receiver queue size: com.atlassian.assets.replication.receiver.queue.size

10000

いいえ

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 AssetsBatchReplicationMessage.

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: com.atlassian.assets.replication.receiver.threads

5

いいえ

Specifies the number of threads polling the AssetsBatchReplicationMessage queue for processing and determines the number of instances of AssetsBatchReplicationMessageWorkQueuePoller.

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: com.atlassian.assets.replication.retry.queue.threads

2

いいえ

Specifies the number of threads polling the retry queue in AssetsReplicationRetryQueuePoller.

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: com.atlassian.assets.replication.retry.queue.attempts

10

はい

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: com.atlassian.assets.replication.retry.queue.interval

60000 ms (1 min)

はい

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 com.atlassian.assets.index.object.load.interval and com.atlassian.assets.index.object.load.attempts properties.

Use this property together with com.atlassian.assets.replication.retry.queue.attempts to adjust the time between the retry attempts.

Dead-letter queue (DLQ) logging interval: com.atlassian.assets.replication.dlq.logger.interval

300000 ms (5 min)

はい

Specifies the interval at which the DLQ is checked for items and a warning is logged. If debug logging is enabled on io.riada.insight.index.replication.poller.AssetsReplicationLogger and the queue isn’t empty, then the queue content will also be logged.

If you need to see the DLQ changes faster, decrease the interval.