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

Bela Ban (JIRA) issues at jboss.org
Fri Sep 9 06:50:03 EDT 2016


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

Bela Ban commented on JGRP-2099:
--------------------------------

The recommendations to use a FJP are:

* must be plain (between 100 and 10,000 basic computational steps in the compute method),
* compute intensive code only,
* no blocking,
* no I/O,
* no synchronization

Timer tasks and messages submitted to a FJP cannot guarantee that they are non-blocking; as a matter of fact messages delivered to an application can block or synchronize, as JGroups has no control over them...


> 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)


More information about the jboss-jira mailing list