[ https://issues.apache.org/jira/browse/SLING-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17628443#comment-17628443 ]
Stefan Egli edited comment on SLING-11662 at 11/3/22 5:36 PM: -------------------------------------------------------------- [~cziegeler], what I was wondering what the idea of the original (current) implementation of blockForAvailableThreads was.. is there a reason it looks at (static) configuration rather than actual threads vs queued runnables? was (Author: egli): [~cziegeler], what I was wondering what the idea of the original (current) implementation of blockForAvailableThreads was.. is there a reason it looks a (static) configuration rather than actual threads vs queued runnables? > Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize > ------------------------------------------------------------------------- > > Key: SLING-11662 > URL: https://issues.apache.org/jira/browse/SLING-11662 > Project: Sling > Issue Type: Bug > Components: Commons > Affects Versions: Commons Scheduler 2.7.12 > Reporter: Stefan Egli > Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When configuring the ThreadPool with maxPoolSize == queueSize and endless > loop (can) happen(s) in QuartzSchedulerThread.run() which manifests as > follows: > {noformat} > "MyPool_QuartzSchedulerThread" #123 prio=5 os_prio=0 cpu=5123456.78ms > elapsed=5163.45s tid=0x000012345678ff00 nid=0x1234 runnable > [0x000087654321ff00] > java.lang.Thread.State: RUNNABLE > at > org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:413) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)