[ 
https://issues.apache.org/jira/browse/RATIS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561092#comment-17561092
 ] 

Tsz-wo Sze commented on RATIS-1603:
-----------------------------------

[~maobaolong], I suspect the  simple example may not be able to test 
ScheduledThreadPoolExecutor since there are no locks inside the task.  In the 
screenshot 
https://issues.apache.org/jira/secure/attachment/13045830/image-2022-06-29-09-33-28-818.png
 , it does show that there are may threads inside ScheduledThreadPoolExecutor.

BTW, would you be able to reproduce the 20k threads situation?  If yes, could 
you try whether https://github.com/apache/ratis/pull/666 can fix it?

> TimeoutScheduler can have a huge amount of threads and cause OOM
> ----------------------------------------------------------------
>
>                 Key: RATIS-1603
>                 URL: https://issues.apache.org/jira/browse/RATIS-1603
>             Project: Ratis
>          Issue Type: Bug
>          Components: util
>    Affects Versions: 2.0.0
>            Reporter: Baolong Mao
>            Assignee: Tsz-wo Sze
>            Priority: Major
>         Attachments: image-2022-06-29-09-33-28-818.png, 
> image-2022-06-29-09-37-07-089.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> !image-2022-06-29-09-33-28-818.png!
> The callstack are same for the 20k threads
> {code:java}
> "java.util.concurrent.ThreadPoolExecutor$Worker@64f771ea[State = -1, empty 
> queue]" #486880 daemon prio=5 os_prio=0 cpu=0.14ms elapsed=35.35s 
> allocated=1696B defined_classes=0 tid=0x00007f136fb65800 nid=0x2130e1 waiting 
> on condition  [0x00007f0f94ccf000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>     at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
>     - parking to wait for  <0x00007f1e0178ef68> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>     at 
> java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:234)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos([email protected]/AbstractQueuedSynchronizer.java:2123)
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take([email protected]/ScheduledThreadPoolExecutor.java:1182)
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take([email protected]/ScheduledThreadPoolExecutor.java:899)
>     at 
> java.util.concurrent.ThreadPoolExecutor.getTask([email protected]/ThreadPoolExecutor.java:1054)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1114)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:628)
>     at java.lang.Thread.run([email protected]/Thread.java:829) {code}
> I found the problem is The following code, we should better give a maxsize 
> for the ScheduledThreadPoolExecutor
>  
> !image-2022-06-29-09-37-07-089.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to