hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naganarasimha G R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2919) Potential race between renew and cancel in DelegationTokenRenwer
Date Thu, 06 Jul 2017 16:38:00 GMT

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

Naganarasimha G R commented on YARN-2919:
-----------------------------------------

Thanks for the review [~jianhe], 
bq. could you elaborate what the race condition is based on code? The jira description is
a bit vague.
Hmm ok i can reword it, but best way to explain would be based on the original [comment|https://issues.apache.org/jira/browse/MAPREDUCE-5384?focusedCommentId=13745421&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13745421]
from Sid which was mentioned by [~kasha] in YARN-2874 . This race is about stopping creation
of the timer task or trying to renew the token if cancel is already invoked on it.

bq. Caller can just make a copy of the token and do all sorts of operation and this flag becomes
moot.
Well agree that if there is a copy made there nothing much which can be done but IIUC its
not the general usage to clone it and it would be useful to avoid unnecessary invoke on the
renew or creation of timer task given that these are multi threaded in nature. In my initial
approach i had created the flag in the RM's {{DelegationTokenToRenew}}, which i think was
rightfully corrected by [~kasha] to be put in Token.

bq. Also, there are some behavior changes, the return value of renew method was supposed to
be the expiration time, now '-1' is returned as an error code, which old program does not
understand - old program was expecting an exception if renew fails. And it's possible for
old program to wrongly interprets the '-1' as the expiration time.
Agree , but the reason i did was api was not clearly mentioning that if its cancelled then
exception will be thrown and it would be left to the renewer (interface) so its implementation
might want to differ but on other hand if expiration is less than before renew check for requesting
new token passes. So i thought its safer, but if you feel its better to throw exception then
would do so but if so then just throw IO Exception ? what if renewer was throwing some subclass?



> Potential race between renew and cancel in DelegationTokenRenwer 
> -----------------------------------------------------------------
>
>                 Key: YARN-2919
>                 URL: https://issues.apache.org/jira/browse/YARN-2919
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.6.0
>            Reporter: Karthik Kambatla
>            Assignee: Naganarasimha G R
>            Priority: Critical
>         Attachments: YARN-2919.002.patch, YARN-2919.003.patch, YARN-2919.004.patch, YARN-2919.005.patch,
YARN-2919.20141209-1.patch
>
>
> YARN-2874 fixes a deadlock in DelegationTokenRenewer, but there is still a race because
of which a renewal in flight isn't interrupted by a cancel. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message