[
https://issues.apache.org/jira/browse/SLING-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050170#comment-18050170
]
Joerg Hoh commented on SLING-13044:
-----------------------------------
As these Timers are only used to later re-inject the jobHandlers into the queue
again (see
[JobQueueImpl::reschedule|https://github.com/apache/sling-org-apache-sling-event/blob/acc0962c1a27d200a040e0e27aca34800f3057ef/src/main/java/org/apache/sling/event/impl/jobs/queues/JobQueueImpl.java#L791]),
we don't need many threads to do this. Most likely a single thread (preferable
managed by a Threadpool for the stability of the service) is sufficient to
handle that task.
> 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)
