Details
-
Bug
-
Resolution: Fixed
-
High
-
5.4
Description
This affects JIRA 6.3-OD3 (probably some previous releases too, but I haven't verified this).
The BackOffScheduler class calls scheduler.shutdown() but this doesn't have effect as threads inside this scheduler are waiting on empty queue, so scheduler won't shutdown. Possible solution is to call shutdownNow() instead. This will work, but it probably will loose any events that are queued (if there are any). On the other hand, JIRA/plugin system is going down when this method is called, so we can't do much here... It might be worth to perform flush before shutdown. Anyway, scheduler need to be terminated.
As the scheduler is not properly shutdown, it still runs after destroy was called. Due to that the thread holds reference to class loader, and pico container cannot be fully freed - 20MB of memory is still hold.
Please also add name for that thread - it's easier to analyse memory dumps then. For example:
newScheduledThreadPool(3, ThreadFactories.namedThreadFactory("MyworkPlugin-BackOffScheduler"));
Also as this code is in common module, I guess that this problem will also affect confluence.
JIRA uses 1.8 version of mywork plugin, but problem still exists in master version. I don't know if JIRA can use latest version of mywork plugin.
BTW, does this code supports 4 and more application links? I'm afraid it won't work for 4+ application link (as all 3 threads will wait on queues). But I didn't analysed it further, so feel free to raise separate issue if that's true .