[wildfly-dev] Logging Changes

Thu Dec 14 16:49:20 EST 2017

On Thu, Dec 14, 2017 at 1:28 PM, Brian Stansberry <
brian.stansberry at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/8e7c35da/attachment.html 