<div dir="ltr">On Tue, Dec 12, 2017 at 12:45 PM, James Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Dec 12, 2017 at 9:37 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Dec 7, 2017 at 5:46 PM, 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"><span>On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>> wrote:<br>
> There will be a slight performance impact during boot. This can be greatly<br>
> reduced if the caller calculation is disabled. This can be done in normal<br>
> cases, but we likely can't make it the default.<br>
<br>
</span>I suspect we can safely disable caller calculation by default on boot,<br>
as long as users have an easy way to turn it on.<br>
<br>
Also I think we should consider some kind of grimy hack to bootstrap<br>
the logging subsystem first, if it's present, otherwise immediately<br>
fall back to properties-based config if it's absent.<br>
<span class="m_3436463271126745014m_6683555855433862172HOEnZb"><font color="#888888"><br></font></span></blockquote></span><div>I'm not sure what counts as first in this context, but fwiw if a logging subsystem is present during boot we always execute it's Stage.RUNTIME steps first before proceeding on to doing the parallel execution of the other subsystems. We could probably without too much trouble get a bit more grimy, e.g. to get the subsystem ops to run before a few others if they don't already. Beyond that I sense we wouldn't be talking grimy, we'd be talking horrible. :)</div></div></div></div></blockquote><div><br></div></span><div>Darran and I had a brief discussion about what we could do because at least parts of Elytron and logging are generally needed before other things are configured. Elytron would likely need to be first because logging will have to use capabilities from it.</div><div><br></div><div>I've wondered if there should be a new Stage.PRE_RUNTIME type of stage, but I can also see where that may get abused. </div></div></div></div></blockquote><div><br></div><div>This is starting to smell bad.</div><div><br></div><div>Elytron needs DS it seems, and DS needs ? and, well, this is why we use MSC. :) We hadn't had deps from logging to other subsystems before, which is what made the minor boot op ordering tricks we do useful, but since we now do, then we're really down to MSC. Boot op ordering tricks can help optimize common cases like a logging subsystem not having elytron dependencies, but I don't think we should try and create a duplicate MSC.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_3436463271126745014m_6683555855433862172HOEnZb"><font color="#888888">
--<br>
- DML<span><br>
______________________________<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></font></span></blockquote></div><span class="m_3436463271126745014HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_3436463271126745014m_6683555855433862172gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</font></span></div></div>
</blockquote></span></div><br><br clear="all"><span class=""><div><br></div>-- <br><div class="m_3436463271126745014gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</div></div>