[
https://issues.apache.org/jira/browse/LOG4J2-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-826:
-------------------------------
Summary: Manage a single Clock and NanoClock instance in Configuration
(was: Manage a single Clock instance in LoggerContext)
> Manage a single Clock and NanoClock instance in Configuration
> -------------------------------------------------------------
>
> Key: LOG4J2-826
> URL: https://issues.apache.org/jira/browse/LOG4J2-826
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Reporter: Remko Popma
>
> 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. Client code
> would get the centrally managed clock instance from the LoggerContext instead
> of querying the ClockFactory.
> The LoggerContext has a life cycle, and clocks that create a background
> thread could become part of this life cycle and stop this thread when the
> LoggerContext is stopped. Starting a new LoggerContext 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
