[jira] [Commented] (LOG4J2-826) Manage a single Clock instance in LoggerContext

["Gary Gregory (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133245#comment-14133245 ] 

Gary Gregory commented on LOG4J2-826:
-------------------------------------

Threaded clocks still need to end their thread's run for a clean shutdown, right?

> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org