...
- We use a timeout of 30s in Jira (or 15s if the queue was sent manually) after which Jira tries to return as fast as possible (it may require a few more seconds). All messages are returned with statuses such as DONE / FAILED (with a message) / NOT_EXECUTED, and with a global error message. This message becomes visible in the Confluence administration.
- We use the double time of 4x this timeout (=60s120s) on the Confluence side. If Jira hasn't answered in 60s120s, we consider all messages as not sent, and we'll try them again in the next batch.
- Emails are only sent to watchers if the "Send notifications" option was chosen in the Requirement Yogi administration, in Jira. Otherwise, history items are just marked as "Notified", so changes performed later will appear as a separate records.
- Emails are not sent if the item stayed in the audit trail for more than 1 hour.
- Locks: We prevent concurrent processing, so even if you have several servers, only 1 queue job, 1 processing on the Jira side, and 1 job of email notifications can be done at the same time.
...
- It is not protected against concurrency yet,
- Messages are created when an issue is renamed, moved to another project, or when requirements are added/removed.
- Every 3 minutes, Jira sends 2000 3000 messages of the queue, with 60s timeout120s timeout (in general, the whole operation takes 3s),
- Confluence responds and has a timeout at 30s, after which all messages are returned as NOT_EXECUTED. The total may take a few seconds more.
- No emails are being sent, only dependencies and Jira issue titles cached in Confluence are saved, it is infinitely faster than in Jira.
- Note that we've measured it could process batches of 50,000 messages sent in 30s every 3 minutes, to enable 1 million messages an hour, but it would require to send requests up to 100MB, and we believe some customers wouldn't handle this. So, unless requested, we'll remain at 2k 3k messages every 3 minutes.
- It processes 4060,000 messages per hour.
How many messages are processed per hour?
...
- All of this was measured with an efficient database. If your database is slower, and even if it is caused by your database having a truely large amount of data, then the queues will process more slowly.
- If Jira, despite stopping at 30s, doesn't respond within 60s 120s to Confluence, then Confluence is going to send again the exact same batch of messages every 3 minutes.
- If you have more than 60,000 queue items per hour, there is no way to increase the performance. The queue will increase until your users create fewer items.
- The queue from Jira to Confluence is not protected yet against concurrency, but it is much faster to send messages.
...