You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Pascal Schumacher (JIRA)" <ji...@apache.org> on 2017/11/10 16:42:01 UTC

[jira] [Closed] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

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

Pascal Schumacher closed LANG-1355.
-----------------------------------

> TimeZone.getTimeZone() in FastDateParser causes resource contention
> -------------------------------------------------------------------
>
>                 Key: LANG-1355
>                 URL: https://issues.apache.org/jira/browse/LANG-1355
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.6
>         Environment: Windows
>            Reporter: Keith Boone
>            Assignee: Charles Honton
>             Fix For: 3.7
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single method getTimeZone() which gets the requested time zone from a ConcurrentMap, and if not present, looks it up via TimeZone.getTimeZone() and caches it before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other applications which heavily parse or format or do other things where TimeZone is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to FastDateParser.parse().  This saves about a ms/call in our test environment, and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)