JSD 3.9.0 attempts to address some of the friction between the SLA system and automation (
JSDSERVER-4743) and poor issue creation performance by introducing a wrapper event type (inspired by OnCommitEvent) and an “expectation” system.
The expectation system gives features that are interested in one or more eligible event types a way to explicitly define the work that should be done before a wrapped event is dispatched, by submitting “jobs” that are executed in the strict cluster-wide order of their submission (no more than one job at a time for each issue) using a thread pool to avoid blocking any request threads (though we just use the submitting thread if it’s not a request thread).
The wrapper event type does the same for the work that should be done after what we refer to as “completion”, by defining @EventListener methods of type public void(ServiceDeskWrappedOnCompletionEvent).
At least two recent support cases have involved severe performance degradation of a node in and/or the database for an instance that seems to have been caused or exacerbated by the expectation system, so we’ll link potential causes to this issue as we find them.
- High CPU usage on DB server
- Increased number of threads used by the Jira process
- High number of SdOffThreadEventJobRunner threads on thread dumps connecting to the database
These steps affect the expectation system such that jobs are always executed immediately on the submitting thread, without touching any OffThreadEventJobRunner or PSMQ code paths, as if the submitting threads are never request threads (
- Go to the dark feature settings page (<baseURL>/secure/SiteDarkFeatures!default.jspa)
- Remove the feature flag sd.internal.base.off.thread.on.completion.events.enabled, if it exists
- Add the following feature flag: sd.internal.base.off.thread.on.completion.events.disabled
- Restart JIRA
SLA accuracy shouldn’t be negatively affected, but issue creation might take longer as a result. WHEN issue created automation rules with SLA-related JQL should still work (