[
https://issues.apache.org/jira/browse/YARN-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909510#comment-13909510
]
Jian He commented on YARN-1363:
-------------------------------
Haven’t looked at the patch deeply, some thoughts
- we don’t need a separate api getIsObtained in GetDelegationTokenResponse,
setting the token as null can be leveraged to indicate not yet obtained.
- what will happen if one operation is in the progress like getDelegationToken
while in the meantime another operation like cancelDelegationToken comes in ?
Thinking whether it’s good to have a state machine per delegation token. We
have 6 events GET,CANCEL,RENEW from client, and STORED, UPDATED, REMOVED from
state store; 3 states, NEW, PROGRESS(or getting, canceling, renewing if needed)
and FINISHED. We should think about all the possible combinations.
> Get / Cancel / Renew delegation token api should be non blocking
> ----------------------------------------------------------------
>
> Key: YARN-1363
> URL: https://issues.apache.org/jira/browse/YARN-1363
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Omkar Vinit Joshi
> Assignee: Zhijie Shen
> Attachments: YARN-1363.1.patch, YARN-1363.2.patch, YARN-1363.3.patch,
> YARN-1363.4.patch, YARN-1363.5.patch, YARN-1363.6.patch, YARN-1363.7.patch
>
>
> Today GetDelgationToken, CancelDelegationToken and RenewDelegationToken are
> all blocking apis.
> * As a part of these calls we try to update RMStateStore and that may slow it
> down.
> * Now as we have limited number of client request handlers we may fill up
> client handlers quickly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
