[
https://issues.apache.org/jira/browse/SLING-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050163#comment-18050163
]
Joerg Hoh commented on SLING-13044:
-----------------------------------
Replacing the java.util.Timer with a ScheduledThreadPoolExecutor is
straightforward, but it leaves open the question how many threads should
actually be used. The ScheduledThreadPoolExecutor allows to configure only the
maximum number of threads, and those are around all the time. That means, that
if we have N job queues the current implementation using Timers have often no
thread around (if no job is scheduled to be retried), with the
ScheduledThreadPoolExecutor we always have at least (a multiple of) N threads
waiting.
Having a single Timer object per JobQueue would limit the total number of
threads to N, but those would be constantly around as well; also a single
unexpectedly terminating TimerTask would render the entire Timer unusable. Not
the best situation either.
Another option is to have a dedicated "RetryService", which is used by every
JobQueue to retry jobs. That could use a single ScheduledThreadPoolExecutor
(with the above mentioned constraints of having all of those threads always
around), but that would be at least independent of the number of JobQueues.
> Job retries can create a large amount of Timers
> -----------------------------------------------
>
> Key: SLING-13044
> URL: https://issues.apache.org/jira/browse/SLING-13044
> Project: Sling
> Issue Type: Improvement
> Components: Event
> Affects Versions: Event Impl 4.4.0
> Reporter: Joerg Hoh
> Priority: Major
>
> When a job needs to be retried, a new Timer with a single TimerTask is
> created. As each Timer creates a controlling thread, a large number of jobs
> to be retried can lead to the creation of a large amount of threads. This
> number is unlimited.
> To control the amount of threads created under such circumstances, a
> ScheduledThreadPoolExecutor should be used, for which we can control the
> number of threads. Each Job Queue should get its own dedicated instance of
> such an executor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
