<div dir="ltr"><div class="gmail_default" style="font-size:large">I think it would be wise for the performance team to test this out at scale using our lab, as I'm sure you would agree.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">If you could point us at a particular build, or point us at what to build, we can do that testing in parallel and give feedback on how this is working.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Thanks.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 8:03 AM, David Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For WildFly 12 I intend to introduce a new thread pool implementation<br>
[1] [2] that will replace most, if not all, uses of ThreadPoolExecutor<br>
in the main codebases of WildFly and WildFly Core, and also in several<br>
support projects such as JBoss MSC and XNIO.<br>
<br>
The thread pool has the following desirable characteristics:<br>
<br>
• Idle threads are always reused before queueing tasks or starting new threads<br>
• The most recently used idle thread is always preferred, which allows<br>
the pool to shrink when it is not fully utilized<br>
• Useful core/max thread pool size distinction<br>
• API-equivalent to ThreadPoolExecutor<br>
• Performance parity with common ThreadPoolExecutor configurations<br>
• Suitable as a replacement for other jboss-threads thread pool types as well<br>
<br>
In addition, it presents the following features:<br>
<br>
• Configure via a builder API<br>
• Configurable exception handler<br>
• Integrated task queue with optional size limit<br>
• Full complement of standard metrics, which can be disabled<br>
• Configurable rejection handler in the form of a handoff executor<br>
• An optional growth-resistance algorithm which can be applied to<br>
larger pools to create growth resistance between the core and maximum<br>
pool size<br>
• An optional post-terminate task<br>
• A few system property based adjustments that can be applied for<br>
experimental purposes<br>
• A global flag which can be set via system property to recommend that<br>
the new thread pool should be disabled, allowing an emergency fallback<br>
in case of an unexpected problem<br>
<br>
Design-wise, the thread pool is based on a special lock-free/wait-free<br>
combination FIFO/LIFO queue algorithm. See [3] for a more complete<br>
explanation of internal operation, if you're curious about the gritty<br>
details.<br>
<br>
This change has a few implications with regards to the application server:<br>
• Thread pools with a core- and max-size which were locked together<br>
may now have these variables decoupled in a safe and useful manner<br>
• Thread pool configurations in the management model which previously<br>
featured only a max size can now have a core size attribute introduced<br>
<br>
Most of the thread pools we use are built and configured within the<br>
wildfly-core code base; that is where the first part of this change<br>
will be done. Later on there will be a follow-up change for WildFly<br>
proper, but this of course can not happen until the core change is<br>
merged and a core release done, so expect that part somewhat later.<br>
The initial WIP change to wildfly-core can be found here [4]. Note<br>
that no pull request will be opened until all the components are<br>
Final. I have done a good deal of testing already, but I will be<br>
doing more CI testing on other platforms and configurations before<br>
submitting the PR.<br>
<br>
I've made an attempt to link up all the JIRAs that are related to this<br>
effort from [1] (either directly or indirectly). If you find another<br>
JIRA that you think is related, or if you have questions or concerns,<br>
ask on this list, or you can ping me directly on HipChat or IRC.<br>
<br>
Thanks!<br>
<br>
[1] <a href="https://issues.jboss.org/browse/JBTHR-38" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/JBTHR-38</a> - Introduce new thread<br>
pool implementation<br>
[2] <a href="https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128" rel="noreferrer" target="_blank">https://github.com/jbossas/<wbr>jboss-threads/commit/<wbr>be95b8d6b42128</a><br>
[3] <a href="https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807a689506af0b70791d93ae81cc1cR67" rel="noreferrer" target="_blank">https://github.com/jbossas/<wbr>jboss-threads/commit/<wbr>be95b8d6b42128#diff-<wbr>f5807a689506af0b70791d93ae81cc<wbr>1cR67</a><br>
[4] <a href="https://github.com/dmlloyd/wildfly-core/tree/threadpool" rel="noreferrer" target="_blank">https://github.com/dmlloyd/<wbr>wildfly-core/tree/threadpool</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
- DML<br>
<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><font size="4">Andrig (Andy) T. Miller<br></font></div><font size="4">Global Platform Director, Middleware<br></font></div><font size="4">Red Hat, Inc.</font><br></div></div></div></div>
</div>