commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention
Date Mon, 09 Oct 2017 02:20:00 GMT


ASF GitHub Bot commented on LANG-1355:

GitHub user chonton opened a pull request:

    LANG-1355: Add FastTimeZone to decrease TimeZone.getTimezone latency

    Adding FastTimeZone to decrease latency of timezone lookups.   I'll hold this PR open
for 48 hours for commons committers' comments.  Thanks!

You can merge this pull request into a Git repository by running:

    $ git pull LANG-1355

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #296
commit a703646e949c277c5249c87e08486d2b7a69cb34
Author: Chas Honton <>
Date:   2017-10-09T01:54:17Z

    LANG-1355: Add FasTimeZone to decrease TimeZone.getTimezone latency

commit 7670979033076f354af7e4cf852709d5403ffbd4
Author: Chas Honton <>
Date:   2017-10-09T02:18:01Z

    Replace all TimeZone.getTimeZone(UTC) wiht FastTimeZone.getGmtTimeZone()


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> -------------------------------------------------------------------
>                 Key: LANG-1355
>                 URL:
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.6
>         Environment: Windows
>            Reporter: Keith Boone
>   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

View raw message