[
https://issues.apache.org/jira/browse/YARN-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757983#comment-13757983
]
Daryn Sharp commented on YARN-1146:
-----------------------------------
Note that bug #2 will not self-correct if the following sequence occurs:
# Issue token 1, 2, 3, 4 (seq=4)
# Renew token 2 (seq=2)
# Cancel token 3, 4 (seq=2)
# Stop RM
# Start RM (seq=2) and will issue token 3 and 4 again
The issue is _probably_ benign given the current implementation, but is a bug
if anything relies on sequence number.
> RM DTSM and RMStateStore mismanage sequence number
> --------------------------------------------------
>
> Key: YARN-1146
> URL: https://issues.apache.org/jira/browse/YARN-1146
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha
> Reporter: Daryn Sharp
>
> {{RMDelegationTokenSecretManager}} implements {{storeNewToken}} and
> {{updateStoredToken}} (renew) to pass the token and its sequence number to
> {{RMStateStore#storeRMDelegationTokenAndSequenceNumber}}.
> There are two problems:
> # The assumption is that new tokens will be synchronously stored in-order.
> With an async secret manager this may not hold true and the state's sequence
> number may be incorrect.
> # A token renewal will reset the state's sequence number to _that token's_
> sequence number.
> Bug #2 is generally masked. Creating a new token (with the first caveat)
> will bump the state's sequence number back up. Restoring the dtsm will first
> set the state's stored sequence number, then re-add all the tokens which will
> update the sequence number if the token's sequence number is greater than the
> dtsm's current sequence number.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
