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

Sam Beroz commented on LOG4J2-896:
----------------------------------

The example above creates a race condition where if the thread is slow to start 
LOGGER could still be null when the main thread tries to dereference it.  I 
could add a lock Object and synchronize on it to ensure LogManager.getLogger() 
has already been called but I think the better answer is to have 
LogManager.getLogger() kickoff the system initialization in a background thread 
and return quickly.  It would then only block in the event you try and write to 
the log and the setup hasn't yet completed.

Thanks - Sam

> Thread System Initialization
> ----------------------------
>
>                 Key: LOG4J2-896
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-896
>             Project: Log4j 2
>          Issue Type: New Feature
>    Affects Versions: 2.1
>         Environment: All
>            Reporter: Sam Beroz
>            Priority: Minor
>
> Some appenders take longer than others to load, notably ones that have to 
> make remote connections (waiting for the SyslogAppender to timeout is 
> painful).  I've noticed a pause in my application as log4j is being 
> configured.  This happens early since I have a static data member call 
> LogManager.getLogger().  I was able to avoid the penalty but initializing the 
> log system in a different thread:
> {code:title=MyClass.java|borderStyle=solid}
>  private volatile static Logger LOGGER;
>   static{
>         Thread thread = new Thread(){
>                 public void run() {
>                         //This will initialize the log system which could 
> incur a timeout cost if the logservice isn't reachable
>                         //subsequent calls to the LOGGER will block until 
> initialization is complete
>                         //starting it here just gives it a head start
>                         LOGGER = LogManager.getLogger(MyClass.class);         
>               }
>         };
>         thread.setDaemon(true);
>         thread.start();
>   }
> {code}
> Could the logic backing LogManager.getLogger() be changed to do something 
> similar in a future release?  This seems like something that could be taken 
> care of behind the scenes.
> Thanks - Sam



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to