That’s right, you were going to do some performance measurements. Please do and let us know what works best.
Ralph > On Jul 4, 2015, at 10:30 PM, Remko Popma <[email protected]> wrote: > > Looks like we already have an outstanding Jira for this: LOG4J2-812 > <https://issues.apache.org/jira/browse/LOG4J2-812>. > If there are no objections I can take care of this one. > > On Sun, Jul 5, 2015 at 9:55 AM, Remko Popma <[email protected] > <mailto:[email protected]>> wrote: > One per logger context would make it easier to clear all ThreadContexts when > a particular logger context is stopped. > > Sent from my iPhone > > On 2015/07/05, at 0:51, Gary Gregory <[email protected] > <mailto:[email protected]>> wrote: > >> Would there be one registry or one per logger context? >> >> Gary >> >> >> -------- Original message -------- >> From: Remko Popma <[email protected] <mailto:[email protected]>> >> Date: 07/04/2015 05:41 (GMT-08:00) >> To: Log4J Developers List <[email protected] >> <mailto:[email protected]>> >> 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 >> <https://plumbr.eu/blog/java/how-is-threadlocal-implemented> ) >> >> Sent from my iPhone >> >> On 2015/07/04, at 20:40, Jess Holle <[email protected] <mailto:[email protected]>> >> wrote: >> >>> On 7/4/2015 2:51 AM, Gary Gregory wrote: >>>> On Thu, Jul 2, 2015 at 6:18 AM, Remko Popma <[email protected] >>>> <mailto:[email protected]>> 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 >>> >
