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