Zhijie Shen commented on YARN-2936:

bq. Maybe a simply way is to do this:

If either write() is called before getProto() or vice versa, the builder object 
is set twice. Is it better to recover the override setters/getters, and 
implement them properly as well as getProto? Similar to what we have done in a 

> 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
> 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

Reply via email to