1:21 p.m.
On Thu, May 8, 2025 at 10:30 AM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
Hi David,
We've had some Zulip discussions over the last few months about getting WF
up to date with JBoss Threads. I've been looking at it some and figured I'd
start a thread, for general status discussions plus to ask a specific
question.
Overall I think there are three things to consider:
1) The AsyncFuture APIs. David added these back into threads 3.9 (thanks!)
so I'll *assume* all is well. We need to test to verify of course.
Correct.
2) Alignment verification. Other libs we integrate use JBoss Threads
3
minors before 3.9 so we'll need to verify the upgrade is ok.
Seems reasonable.
3) The WildFly Core threads module. This is what I've been
looking at. I
plan to:
a) change any resources that provide non-blocking pools to provide to
EnhancedQueueExecutor.
+1
b) change any resources that provide blocking pools to provide the
JBoss
Threads 3 ManagedThreadPoolExecutor.
I would deprecate these and move them to EQE also. See below for
rationale/nuance.
c) For any resources or attributes that are unused in WildFly,
particularly those that involve blocking behavior, deprecate the management
API bits (if not already done) and deprecate the classes for removal.
+1
AFAICT we only have one use of blocking pools in WildFly, which leads
to:
The specific questions for Tomek and David:
The JCA subsystem creates blocking bound queues for its work manager
pools. EnhancedQueueExecutor is non-blocking.
1) Tomek, these should continue to be blocking pools, yes? From my naive
POV, I figure if people are configuring these they have reasons for their
settings and changing pool semantics could be problematic. But I could be
wrong.
2) David, do you have any sense of the perf impact of moving from the
JBoss Threads 2 QueueExecutor (with blocking == true) to the JBoss Threads
3 ManagedThreadPoolExecutor, which basically means moving to the Java SE
ThreadPoolExecutor? Assuming the work manager pools remain as blocking
pools, that switch of underlying pool impl would be the likely migration.
I would still use the EQE on the backend here and avoid using TPE. For
blocking semantics, I'd recommend using a managed wrapper around an ideally
shared backing EQE instance. The wrapper would maintain a semaphore of
submitted tasks (acquire on submit, release on task-complete in a `finally`
block) to allow a maximum of N in-flight tasks before blocking on submit.
This is more robust than falling back to blocking on a filled-queue
situation, as well as being more robust than having more than one thread
pool implementation. It would also be possible to log a debug or trace
event when the threshold is reached. It should be fairly straightforward to
implement; it could be done in wildfly or in jboss-threads if desired.
--
- DML • he/him