| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
This page is about Time to SLA for Jira Server. |
...
Jira On-Prem. |
Time to SLA makes use of every Jira API feature available to minimize load on your Jira instance. Under normal circumstances, TTS functions without a significant effect on performance. But in rare instances, internal effects like a high number of SLAs and external effects like an overall high load on Jira instances and complicated app integrations may cause relatively slower issue loading times after issue transitions.
To remedy this, we’ve created the Asynchronous Update, which allows you to perform SLA updates asynchronously following issue events. This is an optional function that you can enable if SLA calculations are negatively affecting causing your transition times to be delayed.
When does this happen?
...
🤔 When would you need it?
There may be times when Time to SLA has trouble keeping up with issue updates due to numerous automations. Jira's race condition can cause the SLA calculation to be delayed if the JQL condition is changed or updated during workflow transitions. This is due to the fact that the issue's indexing may be completed after Time to SLA begins calculating the SLA, causing JQL to fail.
This could lead to problems with calculations and the wrong information being shown on the SLA Panel. Enabling the Asynchronous Update for the affected SLA on the SLA Configurations screen will get rid of such problems.
This only happens in some rare instances. To remedy this, we’ve created the Asynchronous Update. When you enable this, here’s how the your issue will be calculated:
...
🤔 How does it work?
Since it is not possible to change the way Jira works, Time to SLA offers a limited but effective solution: the Asynchronous SLA calculation method. You can activate the asynchronous SLA calculation for SLAs with this problem, recalculate the existing issues that have this SLA, and investigate the behavior of the plugin. TTS evaluates those SLAs out of issue event cycles so that JQL conditions will return the correct results.
When Asynchronous Update is enabled, the event will be saved in the TTS database. Depending on how often your the task is updated, Time to SLA TTS will calculate the issue and the SLA with a roughly 1-minute delay.
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
We recommend enabling this function only |
...
if any field |
...
in the SLA's JQL condition |
...
may be updated during |
...
workflow transitions. |
...
Keep in mind that, with Asynchronous Update on, Time to SLA will make calculations after issue events occur. |
...
This means that you might expect better issue load times, but there will be a |
...
one-minute delay before |
...
you see the changes on SLAs |
...
SLA configuration’da JQL alanı var. Normalde eğer bu JQL alanı, issue’daki herhangi bir transition sırasında update edilirse, normalde bir sıkıntı olmamasını bekleriz. Ancak Jira’da race condition'ına takılabiliyoruz. Issue’nun indexlenmesi , biz calculation’a başladıktan sonra tamamlanması durumu var. Bu JQL’deki field eğer bu şekilde update edilirse, biz issue’da calculation yaparken indexlemesi bitmediyse, JQL doğru çalışmamış oluyor çünkü daha issue’nun index’i en son haline gelmemiş oluyor. JQL Search de index üzerinden çalışıyor.
Bazı instancelarda yaşanan bir sıkıntı bu. Durum böyle olunca Async ekledik. SLA’iniz için Async seçtiğinizde, o issue’nun hesaplanması şu şekilde gerçekleşiyor:
Bu event’i database’e kaydediyoruz. Şu issue ve SLA için calculation yapacağız şeklinde. Sonra bizim bir task’imiz var. Default olarak dakikada 1 çalışıyor. Ama bunu dilediğinizce değiştirebilirsiniz.
...
. |