[jboss-jira] [JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290441#comment-13290441 ] 

Dan Berindei commented on JGRP-2100:
------------------------------------

I see a potential problem with this approach: even if a task is non-blocking, it could use a lot of CPU. Using the same example of a {{UNICAST3}} retransmission task, if the xmit table is big enough, iterating through the receiver table for 100s of receivers could use too much of the timer thread's CPU allotment.

Having said that, I think the most flexible approach would be to run all tasks on the timer's single thread, and have the tasks themselves decide whether they need to delegate some work to another thread or not. They could even return a `CompletableFuture<Void>`, if you want to make sure you don't re-run the same periodic task until the previous run has finished.

> Timer: don't submit non-blocking tasks to the thread pool
> ---------------------------------------------------------
>
>                 Key: JGRP-2100
>                 URL: https://issues.jboss.org/browse/JGRP-2100
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool.
> If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool.
> Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)