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:
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
