[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=13291087#comment-13291087 ] 

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

Hmm, reading [1] (and part 2 and 3), I'm not convinced FJP is the solution.

What bothers me so far is that a FJP is essentially unbounded and never rejects a task because it is full, but rather blocks or spawns a new thread (when {{ManagedBlocker}} is used). However, I _want_ an exhausted pool to reject tasks (other than non-blocking timer tasks and internal messages)!

So far, I've not managed to see more than {{parallism +1}} threads in the FJP, I need to see if I can create more threads in the pool (e.g. by using ManagedBlocker). IIUIC, FJP uses (unbounded?) queues for each worker. If unbounded, then not good!

[1] http://coopsoft.com/ar/CalamityArticle.html

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