On Thu, Dec 14, 2017 at 1:28 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
What would the system properties look like?
I'm trying to use as few as possible, but right now they are:
* org.jboss.logmanager.bootstrap.enabled - A boolean property that
determines whether or not the queuing should be done.
* org.jboss.logmanager.bootstrap.level - The log level, set on the root
logger, that messages should be logged at. The default is DEBUG for WildFly.
* org.jboss.logmanager.bootstrap.queue-size - The default size of queue.
The default is 10,000 and any messages after that will still be logged,
however the first message is removed from the stack.
* org.jboss.logmanager.bootstrap.calculate.caller - A boolean property that
indicates whether or not the caller should be calculated before the message
is queued. In WildFly we'll have this disabled by default for performance.
* org.jboss.logmanager.bootstrap.fallback.config - This one may or may not
stay. It will likely provide a path to the configuration file to use if a
fallback is needed. A fallback will occur if the JVM exists before the
logging subsystem is comitted or the logging subsystem is not available.
On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins(a)redhat.com> 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
--
James R. Perkins
JBoss by Red Hat