[
https://issues.apache.org/jira/browse/STORM-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908070#comment-14908070
]
Robert Joseph Evans commented on STORM-1069:
--------------------------------------------
System.nanoTime is not necessarily that cheap. System.currentTimeMillis is
reading from a place in shared memory, and incurs little if any overhead.
System.nanoTime on large multi core systems requires coordination between all
of the CPUs to sync them and be sure that it can give that guarantee of a
monotonically increasing value. It is not necessarily that expensive but it is
not that cheap either. For me personally if we don't need sub-millisecond
resolution I would prefer to see the code written so that it still uses
currentTimeMillis but handles the case where now - _lastUpdateMs is negative
and treats it as if time has expired instead of waiting.
> Usage of System.currentTimeMillis() in KafkaSpout can create delays
> --------------------------------------------------------------------
>
> Key: STORM-1069
> URL: https://issues.apache.org/jira/browse/STORM-1069
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-kafka
> Reporter: Dmytro Dragan
> Priority: Trivial
> Labels: newbie
>
> _System.currentTimeMillis()_ returns the current time (wall-clock). Cause of
> this, you can suddenly get too big or even negative duration measured
> operation if between calls _System.currentTimeMillis()_ has changed the time
> ( hours translated to summer / winter time , the adjusted time protocol NTP,
> administrator corrected clock, etc).
> Theoretically, _(now - _lastUpdateMs)_ in 125 line could return negative
> values.
> The better solution is to use _System.nanoTime()_ for measure elapsed time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
