[jira] [Resolved] (LOG4J2-1283) Provide alternative gc-free caching mechanism in DatePatternConverter

["Remko Popma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma resolved LOG4J2-1283.
---------------------------------
       Resolution: Fixed
    Fix Version/s: 2.6

Fixed in master in commit c023a91.

The switch to control which caching is used is {{Constants.ENABLE_THREADLOCALS}}.

> Provide alternative gc-free caching mechanism in DatePatternConverter
> ---------------------------------------------------------------------
>
>                 Key: LOG4J2-1283
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1283
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Core, Pattern Converters
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.6
>
>
> The current caching mechanism used in DatePatternProvider is very fast and does not use ThreadLocals (which can cause memory leaks in web containers). 
> It does however allocate new objects every time the cached value cannot be reused and a new formatted timestamp needs to be created. These objects are: CachedTime, String (plus any objects needed to create this String).
> It should be possible to create an alternative caching mechanism that does not allocate any objects when formatting a date.
> This likely needs to be restricted to FixedDateFormat and perhaps the Unix times, since FastDateFormat creates a number of temp objects for each format invocation (GregorianCalendar, StringBuilder, String).
> Another restriction is that, since this caching mechanism will likely involve ThreadLocals, it is not suitable for web applications.
> I am thinking we may want some switch to determine which caching mechanism to use. This switch may be a general "GC-free" switch since there may be other places where behaviour differs depending on whether we want to be GC-free or not.



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