[jboss-jira] [JBoss JIRA] (JGRP-2099) TP: one single thread pool

[Bela Ban (JIRA)]

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

Bela Ban edited comment on JGRP-2099 at 9/12/16 3:53 AM:
---------------------------------------------------------

OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. Correct: worker queues are not unbounded, but each queue can hold 64M elements!


was (Author: belaban):
OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing.

> TP: one single thread pool
> --------------------------
>
>                 Key: JGRP-2099
>                 URL: https://issues.jboss.org/browse/JGRP-2099
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently, TP has 4 thread pools:
> * OOB
> * Regular
> * Internal
> * Timer (used by TimeScheduler3)
> The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
> This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
> The new common pool would have the following characteristics:
> * Default rejection policy of "abort" (so we can handle pool exhaustion)
> * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
> * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
> * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions



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