[WFCORE-3397] [WFLY-5332] New thread pool proposal

[dmlloyd]

[dmlloyd]

Quick peek link: https://github.com/dmlloyd/wildfly-proposals/blob/threadpool/thread-pool/WFCORE-3397_New%20Thread%20Pool.adoc

[bstansberry]

Thanks for using the JIRA in both the commit message and the PR title. I think that might help with tracking back to any discussion in the comments here, or even just with finding the relevant doc once we have a bunch of them.

[bstansberry]

A key reason we stopped using the threads subsystem is because users could too easily configure an inappropriate pool for a given use case, say a web connector, and then that became a support issue. AIUI a goal of the new pool is that this would no be longer a concern. Can you expand on that a bit in this document?

[dmlloyd]

I've added a 'Previous solutions' section and expanded on a few of the requirements; hopefully that will clarify things.

[dmlloyd]

Here's the current WIP version of the new thread pool extension: https://github.com/dmlloyd/wildfly-core/commit/e5bacff73f. This should be good enough a basis to start working out a test plan, and to get a review of the basic approach before I spread the implementation everywhere else.

The implementation supports fully restartable services which also can (mostly) be updated without requiring a reload. This is done by way of a custom resource type, which was implemented in a way which could be made general, however there might be a better way to go about it.

My goal was to minimize the number of lambdas and classes required to implement this simple subsystem while also allowing correct restartability of services and run time updates, however I still ended up with 18 class files in the end. I feel like we could do better here, but this first pass is good enough for initial code reviews I would think.

/cc @jmesnil @kabir @bstansberry @jamezp @mvinkler

[eguib]

We are using wildfly with a quite big EJB application and are limited by the unbonded thread pool used by the EJB subsystem (because we do not want task queueing and therefore must size the thread pool very high). Also the latest wildfly release is not consistent regarding configuration. The threads subsystem is no longer supported, but still referenced from some subsystems (e.g. when one wants to define a custom thread factory). My first idea to solve our problem described above was to enable the configuration of all supported thread pool variants available in jboss-threads in the ejb subsystem. Then I stumbled over this concept and this seems to go into a different direction.

What is the status of this proposal? If I'm looking at the right places it looks like some of the proposed phases are done (1: Implementation and 2: Initial integration).

• Does approach 1 (revive threads subsystem) mean to stick with the current status but "upgrade" the existing thread pool types to the new implementation? In this case one would still have to improve other subsystems (ejb) to fix the before mentioned configuration gap and possibly support different thread pool implementations.
• Does approach 2 mean there will be a subsystem where one configures thread pools referenced from other subsystems?

I'm willing to invest some time but I'm not sure which approach from the documented phase 3 is the favorite solution. And I do not want to code my own "patch" but rather implement something that has a chance to be merged into master.