logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Log4j2 RollingFileAppender deadlock issue
Date Sat, 04 Jul 2015 12:41:40 GMT
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()
>>> 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

View raw message