[
https://issues.apache.org/jira/browse/LOG4J2-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699718#comment-14699718
]
Bart S. commented on LOG4J2-1094:
---------------------------------
Of course, I was not suggesting that it would. I'm just saying (or I was just
saying) that to me at least manual initialisation is a preferable thing; if the
automatic code in the static of LogManager calls something direct which is not
a side-effect, you just come closer to that scenario. I just believe it is not
a good thing to depend or count on (hardly documented) side effects.
getContext() is just semantically incorrect if your intent is:
{{startContext()}}
or whatever. In general I believe it is bad to let side effects do major work.
I wouldn't mind explaining something in a Jira ticket if that is wanted. I
would rather provide easy to read diagrammed papers or mini papers (articles)
on such things (or whatever) but I am hardly in the position to do so.
I guess it would be the topic of study on some university course. Such things.
I am just making them up with a clear preference of my own. I can only suggest
that something is true. Since it seems to deviate a lot from accepted lore, it
is hard to explain. It is harder to explain without visuals. But I will try
(and hope I don't get shot down).
> 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
>
> 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]
