[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:all-tabpanel ]

Bela Ban updated JGRP-2099:
---------------------------
    Description: 
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

  was:
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 reduce 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



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