There will be a slight performance impact during boot. This can be greatly reduced if the caller calculation is disabled. This can be done in normal cases, but we likely can't make it the default.

On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > There will be a slight performance impact during boot. This can be greatly > reduced if the caller calculation is disabled. This can be done in normal > cases, but we likely can't make it the default. I suspect we can safely disable caller calculation by default on boot, as long as users have an easy way to turn it on. Also I think we should consider some kind of grimy hack to bootstrap the logging subsystem first, if it's present, otherwise immediately fall back to properties-based config if it's absent. I'm not sure what counts as first in this context, but fwiw if a logging

- DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Tue, Dec 12, 2017 at 9:37 AM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd(a)redhat.com&gt; > wrote: > >> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> > There will be a slight performance impact during boot. This can be >> greatly >> > reduced if the caller calculation is disabled. This can be done in >> normal >> > cases, but we likely can't make it the default. >> >> I suspect we can safely disable caller calculation by default on boot, >> as long as users have an easy way to turn it on. >> >> Also I think we should consider some kind of grimy hack to bootstrap >> the logging subsystem first, if it's present, otherwise immediately >> fall back to properties-based config if it's absent. >> >> 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. :) > 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. 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.

> > -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > -- James R. Perkins JBoss by Red Hat

On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > >>>> 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. :) >>> >> >> 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. >> >> 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. >> > > This is starting to smell bad. > > 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. > > Yes I definitely agree. I don't really think adding a new stage is a good idea. The only real reason for logging to need a dependency on Elytron would be to get an SSLContext for sending log messages over a socket. We don't currently have a socket-handler and the syslog handler doesn't currently support SSL. However the syslog server for access logging does. If we don't want to have logging rely on Elytron we'd just have to use the standard way of configuring an SSLContext.

On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd(a)redhat.com&gt; wrote: > On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > > There will be a slight performance impact during boot. This can be > > greatly > > reduced if the caller calculation is disabled. This can be done in > > normal > > cases, but we likely can't make it the default. > > I suspect we can safely disable caller calculation by default on boot, > as long as users have an easy way to turn it on. > > Also I think we should consider some kind of grimy hack to bootstrap > the logging subsystem first, if it's present, otherwise immediately > fall back to properties-based config if it's absent. > 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.

Hi James (all), What you outlined above is similar to effort [1] that was done for JDK 9. Are there are any plans integrating this effort somehow with JDK9 or better reuse what JDK9 already provides? I was doing some research few months back (but I didn't finish it yet) how logging is done in JDK9. I was hoping for better JBoss-Logging integration with JDK9 logging. Although I didn't finish it yet I'm posting here few analysis documents I have created so far. I hope they will be helpful. Rio [1] http://openjdk.java.net/jeps/158 On Thu, Dec 7, 2017 at 9:02 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > Hello All, > For WildFly 12 (maybe not until 13 at this stage) there are some thoughts > on significantly changing the way logging is configured. Currently logging > is initialized by reading a logging.properties file when JBoss Modules > boots. While this works okay there are a few issues with this approach. > > > 1. For boot logging (before the logging subsystem is initialized) you > can't use property expressions. This means when the logging subsystem > rewrites the logging.properties file with all expressions expanded. > 2. Logging objects, such as handlers, cannot use resources from other > subsystems. For example there is a need for a socket-handler. With the > socket handler we need a way to get an SSL context from Elytron. There is > no way for this to be done using a logging.properties file for the boot log > configuration. > 3. If the user want to manually change the logging configuration by > editing the XML they also have to edit the logging.properties. If not the > old configuration will be used until the next boot. > > It would be useful to introduce a way to queue log messages during boot > [1]. Once the logging subsystem boot is complete the messages would be > drained and sent to the new configuration. This of course isn't without > it's own issues. > > > 1. Messages appeared delayed when WildFly is booting. Essentially all > the boot messages are written at once so you see no messages, then all of > them at once. > 2. A shutdown hook would have to be used in order to ensure errors > that cause a boot failure are logged. > 3. This could get a little tricky with offline CLI as currently > logging is configured based on the logging.properties file > 4. If users remove the logging subsystem there are more steps than > just removing logging subsystem to get logging working. > 5. There will be a slight performance impact during boot. This can be > greatly reduced if the caller calculation is disabled. This can be done in > normal cases, but we likely can't make it the default. Note too this is > only a boot impact. Once the logging subsystem takes over, the performance > should be exactly the same as it was before. > > There is some good however too. This does open the door allowing users to > more easily replace the log manager implementation for standalone servers. > Currently we still, and maybe always will, require the JBoss Log Manager to > be used for domain servers, the host controller and process controller. > > It also removes the need for a logging.properties for servers. I think > this is a big bonus to the changes as logging for servers will only be > configured in one place now. Domain will be a bit different, but we should > likely introduce a logging subsystem on the host controller as well. I just > don't think it makes much sense until we can sort out the issues above. > > The current idea is that boot logging will be configurable via system > properties. These properties would have to be set in the JAVA_OPTS. > > I'm curious to hear any concerns others might have about this. This feels > like a rather significant change so I'd rather get it right the first time. > > I have started a design doc, but it's not finalized yet. If you're > curious however you can have at look at it on my topic branch [2]. You can > also see some of the small changes I've made to get it working on WildFly > Core on that branch. > > > [1]: https://issues.jboss.org/browse/LOGMGR-177 > [2]: https://github.com/jamezp/wildfly-core/blob/bootstrap- > logging/logging/bootstrap-logging.asciidoc > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- -- Richard Opalka Principal Software Engineer Red Hat JBoss Middleware Mobile: +420 731 186 942 <+420%20731%20186%20942> E-mail: ropalka(a)redhat.com

What would the system properties look like?

On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > Hello All, > For WildFly 12 (maybe not until 13 at this stage) there are some thoughts > on significantly changing the way logging is configured. Currently logging > is initialized by reading a logging.properties file when JBoss Modules > boots. While this works okay there are a few issues with this approach. > > > 1. For boot logging (before the logging subsystem is initialized) you > can't use property expressions. This means when the logging subsystem > rewrites the logging.properties file with all expressions expanded. > 2. Logging objects, such as handlers, cannot use resources from other > subsystems. For example there is a need for a socket-handler. With the > socket handler we need a way to get an SSL context from Elytron. There is > no way for this to be done using a logging.properties file for the boot log > configuration. > 3. If the user want to manually change the logging configuration by > editing the XML they also have to edit the logging.properties. If not the > old configuration will be used until the next boot. > > It would be useful to introduce a way to queue log messages during boot > [1]. Once the logging subsystem boot is complete the messages would be > drained and sent to the new configuration. This of course isn't without > it's own issues. > > > 1. Messages appeared delayed when WildFly is booting. Essentially all > the boot messages are written at once so you see no messages, then all of > them at once. > 2. A shutdown hook would have to be used in order to ensure errors > that cause a boot failure are logged. > 3. This could get a little tricky with offline CLI as currently > logging is configured based on the logging.properties file > 4. If users remove the logging subsystem there are more steps than > just removing logging subsystem to get logging working. > 5. There will be a slight performance impact during boot. This can be > greatly reduced if the caller calculation is disabled. This can be done in > normal cases, but we likely can't make it the default. Note too this is > only a boot impact. Once the logging subsystem takes over, the performance > should be exactly the same as it was before. > > There is some good however too. This does open the door allowing users to > more easily replace the log manager implementation for standalone servers. > Currently we still, and maybe always will, require the JBoss Log Manager to > be used for domain servers, the host controller and process controller. > > It also removes the need for a logging.properties for servers. I think > this is a big bonus to the changes as logging for servers will only be > configured in one place now. Domain will be a bit different, but we should > likely introduce a logging subsystem on the host controller as well. I just > don't think it makes much sense until we can sort out the issues above. > > The current idea is that boot logging will be configurable via system > properties. These properties would have to be set in the JAVA_OPTS. > > I'm curious to hear any concerns others might have about this. This feels > like a rather significant change so I'd rather get it right the first time. > > I have started a design doc, but it's not finalized yet. If you're > curious however you can have at look at it on my topic branch [2]. You can > also see some of the small changes I've made to get it working on WildFly > Core on that branch. > > > [1]: https://issues.jboss.org/browse/LOGMGR-177 > [2]: https://github.com/jamezp/wildfly-core/blob/bootstrap- > logging/logging/bootstrap-logging.asciidoc > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat

I'm not so clear on a lot of the gritty details here, but I would caution against any sort of shutdown hook usage. For the embedded use case this is a bit of a problem, since they stack up until the user finally quits. There is a fairly clear need for an abstraction that executes on some sort of "executed unit of work," basis vs actually ends up calling exit().

Ken On Thu, Dec 7, 2017 at 3:58 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > Hello All, > For WildFly 12 (maybe not until 13 at this stage) there are some thoughts > on significantly changing the way logging is configured. Currently logging > is initialized by reading a logging.properties file when JBoss Modules > boots. While this works okay there are a few issues with this approach. > > > 1. For boot logging (before the logging subsystem is initialized) you > can't use property expressions. This means when the logging subsystem > rewrites the logging.properties file with all expressions expanded. > 2. Logging objects, such as handlers, cannot use resources from other > subsystems. For example there is a need for a socket-handler. With the > socket handler we need a way to get an SSL context from Elytron. There is > no way for this to be done using a logging.properties file for the boot log > configuration. > 3. If the user want to manually change the logging configuration by > editing the XML they also have to edit the logging.properties. If not the > old configuration will be used until the next boot. > > It would be useful to introduce a way to queue log messages during boot > [1]. Once the logging subsystem boot is complete the messages would be > drained and sent to the new configuration. This of course isn't without > it's own issues. > > > 1. Messages appeared delayed when WildFly is booting. Essentially all > the boot messages are written at once so you see no messages, then all of > them at once. > 2. A shutdown hook would have to be used in order to ensure errors > that cause a boot failure are logged. > 3. This could get a little tricky with offline CLI as currently > logging is configured based on the logging.properties file > 4. If users remove the logging subsystem there are more steps than > just removing logging subsystem to get logging working. > 5. There will be a slight performance impact during boot. This can be > greatly reduced if the caller calculation is disabled. This can be done in > normal cases, but we likely can't make it the default. Note too this is > only a boot impact. Once the logging subsystem takes over, the performance > should be exactly the same as it was before. > > There is some good however too. This does open the door allowing users to > more easily replace the log manager implementation for standalone servers. > Currently we still, and maybe always will, require the JBoss Log Manager to > be used for domain servers, the host controller and process controller. > > It also removes the need for a logging.properties for servers. I think > this is a big bonus to the changes as logging for servers will only be > configured in one place now. Domain will be a bit different, but we should > likely introduce a logging subsystem on the host controller as well. I just > don't think it makes much sense until we can sort out the issues above. > > The current idea is that boot logging will be configurable via system > properties. These properties would have to be set in the JAVA_OPTS. > > I'm curious to hear any concerns others might have about this. This feels > like a rather significant change so I'd rather get it right the first time. > > I have started a design doc, but it's not finalized yet. If you're > curious however you can have at look at it on my topic branch [2]. You can > also see some of the small changes I've made to get it working on WildFly > Core on that branch. > > > [1]: https://issues.jboss.org/browse/LOGMGR-177 > [2]: https://github.com/jamezp/wildfly-core/blob/ > bootstrap-logging/logging/bootstrap-logging.asciidoc > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev