[wildfly-dev] Moving to JBoss Threads 3.9.x

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