[
https://issues.apache.org/jira/browse/LOG4J2-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-826:
-------------------------------
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. 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.
was:
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.
> Manage a single Clock instance in LoggerContext
> -----------------------------------------------
>
> 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
