[
https://issues.apache.org/jira/browse/YARN-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Saxena updated YARN-2936:
-------------------------------
Attachment: YARN-2936.006.patch
> 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, YARN-2936.002.patch,
> YARN-2936.003.patch, YARN-2936.004.patch, YARN-2936.005.patch,
> YARN-2936.006.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)
