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
8 months
Help Wanted! -- Assets to transfer to Commonhaus
by Brian Stansberry
WildFly joining Commonhaus was formally announced today. :-) (See [1]). As
I noted in the announcement, we're now beginning the process of onboarding
to Commonhaus. Part of that is identifying the various 'assets' that will
be transferred from Red Hat to Commonhaus.
HELP WANTED on this! We have an opportunity to proceed more quickly on this
asset transfer piece than I thought, but only if we act promptly to provide
information.
I have created a google document at [2] to record details of various types
of assets we will transfer. I can really use your help with adding anything
that is missing. Anyone can comment on the doc, so simplest is to directly
edit the file to add things; your edits will be recorded as suggestions.
I'm looking for things in 5 categories -- 'Source Code Repositories',
'Domain Names', 'Hosting Accounts', 'Social Media and Email Accounts' and
'Trademarks'. The google doc has definitions of these, and from the ones
I've already entered you can get a sense of the basic idea.
When in doubt, suggest it! And leave a comment about the doubt.
Note that the discussion of the scope of 'WildFly' on the 'Applying to
Commonhaus' thread is relevant, so part of doing this will be firming up
things discussed there. (If something discussed there is not covered in my
initial draft of the doc; don't read anything into that, just help me by
pointing that out.)
NOTE: This DOES NOT need to be perfect. We can correct errors, add missing
things, etc. So don't stress out.
[1] https://www.wildfly.org/news/2025/04/30/WildFly-Commonhaus/ and
https://www.commonhaus.org/activity/259.html
[2]
https://docs.google.com/document/d/1qak1F2caFORP2kmDFZI68NsdVkXbslvKndCbe...
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
8 months
