logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1094) Multi thread initialization problem
Date Wed, 27 Apr 2016 07:53:13 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259610#comment-15259610
] 

Remko Popma edited comment on LOG4J2-1094 at 4/27/16 7:53 AM:
--------------------------------------------------------------

Wouldn't it be easier to block until the user-specified configuration has been swapped in?

What about this: rather than _always_ starting with a DefaultConfiguration that allows the
user to start logging but which will be replaced when the user-specified configuration has
been loaded, an alternative would be to _first_ scan if a user-specified configuration exists,
and try to load that. So we would only use the DefaultConfiguration when no user-specified
configuration exists. 

Calls to LogManager.getLogger() can then block until the configuration (either the user-specified
or the Default fallback) has been fully loaded.

The SLF4J solution feels a bit hacky.... Not sure if we want to imitate it. If you think about
it, we only want to route to this temporary ListAppender if we _know_ that a user-specified
config will replace the current DefaultConfiguration. (Otherwise we will blow up our memory.)
If we know that much, we might as well just load the real config...

The only drawback is that user code will block until Log4j initialization completes, which
may cause slow startup time in user apps. 


was (Author: remkop@yahoo.com):
Wouldn't it be better to block until the user-specified configuration has been swapped in?

> Multi thread initialization problem
> -----------------------------------
>
>                 Key: LOG4J2-1094
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1094
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.3
>            Reporter: Luca Burgazzoli
>            Assignee: Ralph Goers
>
> I wrote a very simple example which has a behaviour I do not expect:
> If I call LogManager.getLogger(..) from two threads, only one of the loggers logs what
I'd expect but if I add an additional call to LogManager.getLogger(..) before the threads
are started, I see what I'd expect so it looks like there is a problem in multi threaded initialization.
> You can find the code and the configuration here:
> - https://github.com/lburgazzoli/lb-chronicle/blob/master/chronicle-examples/chronicle-logger-log4j2/src/main/java/com.github.lburgazzoli.openhft.examples.chronicle.logger.log4j2/MtLogging.java
> - https://github.com/lburgazzoli/lb-chronicle/blob/master/chronicle-examples/chronicle-logger-log4j2/src/main/resources/log4j2.xml
> {code}
> public class MtLogging {
>     public static void main(final String[] args) throws Exception {
>         //LogManager.getLogger("main");
>         Thread th1 = new Thread(() -> {
>             final String name = "thread-1";
>             final Logger log = LogManager.getLogger(name);
>             System.out.println("write " + name);
>             log.info("message");
>             System.out.println("done " + name);
>         });
>         Thread th2 = new Thread(() -> {
>             final String name = "thread-2";
>             final Logger log = LogManager.getLogger(name);
>             System.out.println("write " + name);
>             log.info("message");
>             System.out.println("done " + name);
>         });
>         th1.start();
>         th2.start();
>         th1.join();
>         th2.join();
>     }
> }
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration>
>     <appenders>
>         <Console name="STDOUT" target="SYSTEM_OUT">
>             <PatternLayout pattern="[TEST] [%-5p] %c - %m%n%throwable{none}"/>
>         </Console>
>     </appenders>
>     <loggers>
>         <root level="all">
>             <appender-ref ref="STDOUT"/>
>         </root>
>     </loggers>
> </configuration>
> {code}
> The code above will show:
> {noformat}
>     write thread-1
>     done thread-1 
>     write thread-2
>     [TEST] [INFO ] thread-2 - message
>     done thread-2
> {noformat}
> Any call to LogManager makes it succeed (the problem no longer occurs):
> {code}
>     LogManager.getContext(false);
>     th1.start();
>     th2.start();
>     th1.join();
>     th2.join();
> {code}
> New output:
> {noformat}
>     write thread-2
>     write thread-1
>     [TEST] [INFO ] thread-2 - message
>    done thread-2
>    [TEST] [INFO ] thread-1 - message
>    done thread-1
> {noformat}
> The funny thing is that the first thread to arrive is initialized with ERROR level instead
of the ALL that is given to root. In other words it seems that the config has not loaded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message