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

Remko Popma commented on LOG4J2-702:
------------------------------------

Ah, yes, I only increased its visibility, that's right. No objection to moving 
this method, btw.

I'm looking at the retry design. So far I haven't found any fault with it. I'll 
keep looking.

One thing: instead of retrying once (with an if), the standard idiom with 
lock-free designs like this seems to be a while loop that continues until it 
succeeds. We could have some max-attempts circuit breaker, but (as you pointed 
out) then what do we do with the event that we haven't been able to log? Log it 
to some error appender? Throwing an exception would disrupt the application 
which seems undesirable.

> LoggerConfig#waitForCompletion is not thread safe
> -------------------------------------------------
>
>                 Key: LOG4J2-702
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-702
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0-rc2
>            Reporter: Sean Bridges
>            Assignee: Matt Sicker
>            Priority: Critical
>             Fix For: 2.0
>
>
> This is in trunk, svn commit 1608156
> LoggerConfig#waitForCompletion uses an AtomicInteger counter to try to detect 
> if there are any calls currently executing the log(Event) method, but it does 
> not do so in a thread safe manner.  Consider two threads A and B, where 
> Thread A is calling clearAppenders(), and Thread B is calling log(Event),
> {code}
> Thread A  loggerConfig.clearAppenders()
> Thread A  loggerConfig.waitForCompletion()
> Thread A  counter.get() //returns 0
> Thread A  //loggerConfig.waitForCompletion() returns
> Thread B  loggerConfig.log(Event)
> Thread B  counter.increment()
> Thread A  proceeds assuming no log calls are onging, but thread B is in the 
> log method
> {code}
> I'm not sure what the requirements are, but if the requirement is to not lose 
> logging events, I think you need some sort of synchronization outside of the 
> LoggerConfig object.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Reply via email to