Remko Popma created LOG4J2-826:
----------------------------------
Summary: 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
