[
https://issues.apache.org/jira/browse/LOG4J2-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-1283:
-----------------------------------
Assignee: Remko Popma
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
