<div dir="ltr"><div class="gmail_default" style="font-size:large">Sounds good. If we have time this next week, we will see about getting a first test done during our face to face week. It's a very busy week though, so we may not be able to until after next week.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Thanks for the pointers.</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 9:33 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">The proposed change can be found here:<br>
<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>
<br>
You can build that wildfly-core and then build a wildfly which uses<br>
the produced build. The whole process with -DskipTests should take<br>
under 10 minutes. I would be very happy to know what the performance<br>
team finds, particularly in high-contention scenarios. Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 3, 2017 at 10:17 AM, Andrig Miller <<a href="mailto:anmiller@redhat.com">anmiller@redhat.com</a>> wrote:<br>
> I think it would be wise for the performance team to test this out at scale<br>
> using our lab, as I'm sure you would agree.<br>
><br>
> If you could point us at a particular build, or point us at what to build,<br>
> we can do that testing in parallel and give feedback on how this is working.<br>
><br>
> Thanks.<br>
><br>
> Andy<br>
><br>
> On Fri, Nov 3, 2017 at 8:03 AM, David Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br>
>><br>
>> 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<br>
>> 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<br>
>> 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]<br>
>> <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>
>><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><br>
><br>
><br>
><br>
><br>
> --<br>
> Andrig (Andy) T. Miller<br>
> Global Platform Director, Middleware<br>
> Red Hat, Inc.<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
- DML<br>
</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>