<div dir="ltr"><div>Hi All,<br><br></div> comments in-line:<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 8:31 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks, Richard. Comments in-line.<div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Thu, Jan 4, 2018 at 7:56 AM, Richard Opalka <span dir="ltr"><<a href="mailto:ropalka@redhat.com" target="_blank">ropalka@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi everyone,<br><br></div> I would like to outline a brief JBoss MSC Plans for Year 2018.<br><div><div><br></div><div>Goals defined below address both:<br> * Cloud First Effort<br> - Reduce WildFly memory footprint<br></div></div></div></blockquote><div><br></div></span><div>Do you have a sense of how much we're talking about here, e.g. from a standalone server using the standalone-full.xml config and no deployments?</div></div></div></div></blockquote><div><br></div><div>If we'd replace injections, values and injectors with new MSC2 like dependencies than I think we would be still talking about just small memory improvements.</div><div>But such change might have better impact on MSC performance (from concurrency point of view).</div><div>Anyway main reason of doing it is to approach MSC1 to MSC2 as much as possible.</div><div>Then potential switch from MSC1 to MSC2 in the future would be more straightforward process.<br></div><div></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> - Speed up WildFly boot time<br></div></div></div></blockquote><div><br></div></span><div>Same question here. A reload takes a couple hundred ms of which my guess is MSC is a quite small part.</div></div></div></div></blockquote><div><br></div><div>The improvement here might be better comparing to memory improvements.</div><div>Simplified MSC state machine (and less MSC states) results in less context switches.</div><div>I have a local prototype where we have been able to eliminate one third of MSC states</div><div>(and I believe we could simplify MSC state machine even further in the future).<br></div><div>I don't have numbers yet but this change should improve WildFly boot process and deployments.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> * Potential Migration to MSC 2<br><br>MSC Library Goals:<br> * SHORT TERM GOALS (MSC 1.2.x, 1.3.x)<br> [1] simplify MSC state machine - deprecate useless MSC internal states<br> (e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)<br> [2] deprecate API exposing MSC internals<br> (e.g. replace ServiceListener with LifecycleListener)<br> [3] deprecate MSC Values, Injections & Injectors and provide alternative API<br> (alternative API should have same minimalistic memory requirements like MSC 2)<br> * LONG TERM GOALS (MSC 1.4.x)<br> [4] remove deprecated APIs and all deprecated stuff<br><br>WildFly MSC Integration Goals:<br> + SHORT TERM GOALS (WildFly 12)<br> * replace ServiceListeners with LifecycleListeners (LifecycleListeners don't expose MSC internals)<br> * eliminate MSC optional dependencies from WildFLy Core<br></div></div></div></blockquote><div><br></div></span><div>Sounds good. The basic issue there is the modeling of optional module dependencies using MSC services, and IIRC you have an alternate approach in mind. </div></div></div></div></blockquote><div><br></div><div>I didn't give it much thinking yet, but at the moment there are two alternatives I am aware of:</div><div>1) Let JBoss Modules do handling of optional dependencies on its own and don't map optional modules to MSC optional dependencies</div><div> - the idea is present in this commit: <a href="https://github.com/ropalka/wildfly-core/commit/c65841c1892f02e14a14101cca4035f89c932ce5">https://github.com/ropalka/wildfly-core/commit/c65841c1892f02e14a14101cca4035f89c932ce5</a></div><div> (and all WildFly-Core and WildFly testsuites are passing with this commit)<br></div><div>2) Workaround MSC optional dependencies for optional modules somehow<br></div><div> - that's my next TODO task<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>DomainModelControllerService also has one for some reason but I figure that can be eliminated easily enough.</div></div></div></div></blockquote><div><br></div><div>This I hope should be easy to workaround via capabilities (i.e. install REQUIRED dependency iff some capability is present).<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> * eliminate MSC Values, Injections & Injectors and migrate to alternative API<br></div></div></div></blockquote><div><br></div></span><div>This sounds like a very large task for WF 12, for which only some weeks of dev time remain.</div></div></div></div></blockquote><div><br></div><div>This sounds more complex than it is. But of course there can be use cases that might complicate this task.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> * WildFly Management Layer should not expose MSC APIs as its public API<br> (complicates potential migration to MSC2 and breaks encapsulation)<br></div></div></div></blockquote><div><br></div></span><div>I can't see this happening in WildFly 12. Let's talk about it when we meet up at the end of the month.</div></div></div></div></blockquote><div><br></div><div>We definitely need to talk about it and come to a conclusion.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><div dir="ltr"><div><div> + LONG TERM GOALS (WildFly versions targeting next major EAP)<br> * eliminate MSC optional dependencies from WildFly (probably via Capabilities)<br> (MSC Optional Dependencies have been fixed recently but there's still performance issue<br> - in worst case scenario if service A has N optional dependencies<br> it may happen service A is restarted N times before it is stabilized in UP state)<br><br>Feedback and comments more than welcome!<span class="gmail-m_3796116366533042320HOEnZb"><font color="#888888"><br clear="all"><br>-- <br></font></span></div><span class="gmail-m_3796116366533042320HOEnZb"><font color="#888888"><div>Rio</div><br></font></span></div></div>
<br></span><span class="gmail-">______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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/mailma<wbr>n/listinfo/wildfly-dev</a><br></span></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_3796116366533042320gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</font></span></div></div>
</blockquote></div><br></div><div class="gmail_extra">Thanks for asking.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div>Rio<br></div></div>
</div></div>