Currently, we are developing a new task that takes too much time to be processed with a large dataset. Our code is already super optimized and the time it takes is really due to the amount of data.
This process doesn’t need to give real-time feedback to the user so we were thinking on running it on background, using threads. This way, the task could be processed in background and the user doesn’t get stuck waiting to get the control back.
Do you think it’s a good idea? Does Jira have any recommendation regarding it? Will it cause any impact on Jira, especially on Data Center?
@nunosantos, having a background task to do the heavy lifting is actually a recommended practice. You can use an event listener or rely on a scheduled task (using the Scheduler API). If you use the Scheduler API, you will be able to make sure your background task is compatible with Data Center installations.
I have several large customers using one of my apps to synchronise project versions, with replication between many projects, all having a lot of versions. By leveraging the Scheduler API (run multiple jobs, each with a different interval) and Caching API I can limit the performance on both the database and the host instance.
Hi @remie, thank you for your input. It really helped us to figure out which approach we should take.
Currently, we are thinking of using the Scheduler API in our upgrade task which will be responsible to make a pre-calculation of the required data and then store it in a custom field. For common user actions, we are going to use event listeners with the AsynchronousPreferred annotation. In both cases, the data doesn’t need to be updated in real time so we think it should work pretty well. We’ll also use timestamps to make sure the data stored is actually the last results.
Long running tasks
You should avoid long-running tasks in shared thread pools as they may impact other core tasks. For example, tasks that run in response to application events, indexing tasks and scheduled jobs. If these long-running tasks are required, you should move them to a separate executor and consider what should happen if the executor cannot keep up with the tasks being scheduled. Can tasks be dropped safely? Can tasks be batched to run more efficiently?
I would interpret this as “If you have long-running tasks, have event listeners or schedulers start you a thread that actually does the heavy lifting”, correct (i.e. do not use the event listener or scheduler thread)?
@tobitheo a yes, I should have clarified this, good catch!
So the general idea is that you use the Scheduler API or event system to offload tasks that can be done in the background. Once the event or scheduled job is triggered, you make sure to run the task using a separate executor (see java.util.concurrent.ExecutorService).
I’d also suggest using checkpoints/batches along the way depending on the job. Ie if you’re triggering something that will take 2 hours - break it into 24 chunks (eachb10mins). That way if Jira gets kicked you don’t start back at 0.
After issue update I want to do stuff (jql, another issue update) asynchronously in the listener
I saw AsynchronousPreferred docs
in Jira but there isn’t any example how to use it.
Can you assist