[LOG4J2-826] Manage a single Clock and NanoClock instance in Configuration

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: Core
• Assignee: Unassigned
• Reporter: Remko Popma
• Created: 14/Sep/14 14:40
• Updated: 14/Nov/15 06:19

Description

LOG4J2-819 brought to light a number of weaknesses and inconsistencies in the way Clocks are created and managed.

• ClockFactory.getClock() creates a new instance for some clocks, but returns singleton instances for other clocks. It may be more consistent to always return a new instance and make it the caller's responsibility to manage this clock.
• Some clock implementations create a background thread and are implemented as singletons to prevent creation of unnecessary threads. In some execution environments like web containers this singleton design may clash with their use of class loaders and cause memory leaks.

One solution to these issues is to stop using singletons for clock implementations. ClockFactory.getClock() would return a new clock instance on every invocation. This implies that client code should no longer use ClockFactory.getClock() to get a clock instance or a new thread may be created with every call.

Instead, Log4j would create a single clock instance once at startup, and manage this instance in a well-known location like LoggerContext or Configuration. Client code would get the clock instance from the centrally managed location instead of querying the ClockFactory.

LoggerContext and Configuration have a life cycle, and clocks that create a background thread could become part of this life cycle and stop this thread when the LoggerContext or Configuration is stopped. Starting a new LoggerContext/Configuration would create a new clock. This would enable clocks that start a background thread to be used in web containers.

---

Update Nov 2015:

Similarly for the NanoClock that was introduced with LOG4J2-1074. The NanoClock implementation may vary with the Configuration (it is only switched on if the configuration has a layout that requires nanotime time stamps). Hence the best place to manage clocks may actually be in the Configuration.

Currently there are two classes that "own" a Clock and a NanoClock: AsyncLogger and Log4jLogEvent. AsyncLogger's updateConfiguration method is called when the configuration changes, so for AsyncLogger getting the Clocks from the Configuration would not be a big change.

Log4jLogEvent does not (and should not) have a reference to the Configuration, so this is a larger change.

Issue Links

• is related to: LOG4J2-1074 Add a logformat token for nanotime
• supercedes: LOG4J2-819 PermGen OutOfMemoryError when reloading webapp on Tomcat 6