[ 
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 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.

  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.

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


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



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

Reply via email to