[
https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin....
]
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)