logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Log4j2 RollingFileAppender deadlock issue
Date Sat, 04 Jul 2015 15:51:35 GMT
Would there be one registry or one per logger context?
Gary 

-------- Original message --------
From: Remko Popma <remko.popma@gmail.com> 
Date: 07/04/2015  05:41  (GMT-08:00) 
To: Log4J Developers List <log4j-dev@logging.apache.org> 
Subject: Re: Log4j2 RollingFileAppender deadlock issue 

ThreadLocal is implemented as an internal Map in each Thread instance, so there is constant
lookup time regardless of the number of Threads and the number of lookups. Contrast this with
a lock, where performance will decrease exponentially with more concurrent threads. 
(See also https://plumbr.eu/blog/java/how-is-threadlocal-implemented )
Sent from my iPhone
On 2015/07/04, at 20:40, Jess Holle <jessh@ptc.com> wrote:


  
    
  
  
    On 7/4/2015 2:51 AM, Gary Gregory
      wrote:

    
    
      
      
        
          On Thu, Jul 2, 2015 at 6:18 AM, Remko
            Popma <remko.popma@gmail.com>
            wrote:

            
              
                Yes, that could still work: We could use a
                  ThreadLocal containing a custom class which holds the
                  lastTimestamp, cachedDateString as well as a
                  SimpleDateFormat instance. 
                

                
                As Jess pointed out, we would also need a way to
                  clear the ThreadLocal when the LoggerContext is
                  stopped (to prevent memory leaks in web apps). This
                  may be the third usage of ThreadLocals in log4j2 now,
                  so it may be worth creating a reusable mechanism for
                  this. 
                One idea would be to have a ThreadLocal registry in
                  the LoggerContext, where the LoggerContext is
                  responsible for cleaning up all registered
                  ThreadLocals in its stop() method. 
                

                
                Thoughts?

                
              
            
            

            
            I'm wondering what the performance cost are of doing a
              ThreadLocal.get() vs. synchronized(this) on each call to
              format().
            

          
        
      
    
    Personally I'd be less concerned with optimizing maximum logger
    throughput on any given thread than:

    
      Ensuring that not logging takes minimal time
      Minimizing potential thread contention
    
    Logging at maximum efficiency is a priority, but comes after
      these others.

    
    --

      Jess Holle

      

    
  

Mime
View raw message