[
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198912#comment-16198912
]
ASF GitHub Bot commented on LANG-1355:
--------------------------------------
Github user PascalSchumacher commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/296#discussion_r143781416
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -39,10 +43,11 @@ public static TimeZone getGmtTimeZone() {
/**
* Get a TimeZone, looking first for GMT custom ids, then falling back
to Olson ids.
- * A GMT custom id has an optional prefix of GMT, followed by sign,
hours digit(s), optional
- * colon(':'), and optional minutes digits: <em>[GMT] (+|-) Hours [[:]
Minutes]</em>
+ * A GMT custom id can be 'Z', or 'UTC', or has an optional prefix of
GMT,
+ * followed by sign, hours digit(s), optional colon(':'), and optional
minutes digits.
+ * i.e. <em>[GMT] (+|-) Hours [[:] Minutes]</em>
*
- * @param id A GMT custom id or Olsen id
+ * @param id A GMT custom id (or Olson id
--- End diff --
Nitpick: either a superfluous `(` or a missing `)`
> 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
> 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)
