logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Log4j2 RollingFileAppender deadlock issue
Date Sat, 04 Jul 2015 11:40:01 GMT
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 
> <mailto: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:

 1. Ensuring that /not/ logging takes minimal time
 2. Minimizing potential thread contention

Logging at maximum efficiency is a priority, but comes after these others.

Jess Holle

View raw message