[ 
https://issues.apache.org/jira/browse/YARN-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259320#comment-14259320
 ] 

Varun Saxena commented on YARN-2936:
------------------------------------

bq. Maybe a simply way is to do this.
Hmm...Sounds better. Will make the change.

> YARNDelegationTokenIdentifier doesn't set proto.builder now
> -----------------------------------------------------------
>
>                 Key: YARN-2936
>                 URL: https://issues.apache.org/jira/browse/YARN-2936
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Zhijie Shen
>            Assignee: Varun Saxena
>         Attachments: YARN-2936.001.patch
>
>
> After YARN-2743, the setters are removed from YARNDelegationTokenIdentifier, 
> such that when constructing a object which extends 
> YARNDelegationTokenIdentifier, proto.builder is not set at all. Later on, 
> when we call getProto() of it, we will just get an empty proto object.
> It seems to do no harm to the production code path, as we will always call 
> getBytes() before using proto to persist the DT in the state store, when we 
> generating the password.
> I think the setter is removed to avoid duplicating setting the fields why 
> getBytes() is called. However, YARNDelegationTokenIdentifier doesn't work 
> properly alone. YARNDelegationTokenIdentifier is tightly coupled with the 
> logic in secretManager. It's vulnerable if something is changed at 
> secretManager. For example, in the test case of YARN-2837, I spent time to 
> figure out we need to execute getBytes() first to make sure the testing DTs 
> can be properly put into the state store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to