Moving to JBoss Threads 3.9.x
by Brian Stansberry
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.
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.
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.
b) change any resources that provide blocking pools to provide the JBoss
Threads 3 ManagedThreadPoolExecutor.
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.
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.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year
