[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
