[
https://issues.apache.org/jira/browse/YARN-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297681#comment-14297681
]
Jason Lowe commented on YARN-3114:
----------------------------------
If my math is correct, we won't have this problem for about 292,277 millennia.
IMHO this is effectively a non-issue, as we would be so lucky for this code to
be in use when that becomes a problem. ;-)
On a separate note, the unit test doesn't actually test the code that was
changed. It just asserts that the JVM is performing math correctly with Longs.
The change in DelegationTokenRenewer could later regress while the unit test
continues to pass, which doesn't make it a very effective unit test.
> It would be better to consider integer(long) overflow when compare the time
> in DelegationTokenRenewer.
> ------------------------------------------------------------------------------------------------------
>
> Key: YARN-3114
> URL: https://issues.apache.org/jira/browse/YARN-3114
> Project: Hadoop YARN
> Issue Type: Bug
> Components: resourcemanager
> Reporter: zhihai xu
> Assignee: zhihai xu
> Priority: Minor
> Attachments: YARN-3114.000.patch
>
>
> It would be better to consider integer(long) overflow when compare the time
> in DelegationTokenRenewer.
> When compare time in DelegationTokenRenewer#DelayedTokenRemovalRunnable to
> cancel token , it will have problem when currentTimeMillis is close to
> Long.MAX_VALUE.
> The safer way to compare time will compare the time difference:
> change
> {code}
> if (e.getValue() < System.currentTimeMillis()) {
> {code}
> to
> {code}
> if (e.getValue() - System.currentTimeMillis() < 0) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
