You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Rohith Sharma K S (JIRA)" <ji...@apache.org> on 2016/11/14 10:01:09 UTC
[jira] [Comment Edited] (YARN-5865) Retrospect
updateApplicationPriority api to handle state store exception in align with
YARN-5611
[ https://issues.apache.org/jira/browse/YARN-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15662917#comment-15662917 ]
Rohith Sharma K S edited comment on YARN-5865 at 11/14/16 10:00 AM:
--------------------------------------------------------------------
Thanks Sunil for the patch.. couple of things to consider,
# As Jian comment, need to update state-store first and update in-memory second. But this would be difficult in priority update as it try to update ApplicationSubmissionContext. I think this is time to think for storing priority in ApplicaitonStateData. As I see storing priority as separate field in ApplicationStateData would be a difficult for priority update to change some of the implementation part especially during submission and recovery flow, but I think it is good to do it now. Thoughts?
# I see one race conditional bug since we are holding lock on applicationId. It is there in update ApplicationTimeout also. Could we do {{if (COMPLETED_APP_STATES.contains(application.getState())) {}} check either after holding lock of applicationId or in method {{RMStateStore#updateApplicationStateSynchronously}} ?? And could you update this modification for updateTimeout also?
was (Author: rohithsharma):
Thanks Sunil for the patch.. couple of things to consider,
# As Jian comment, need to update state-store first and update in-memory second. But this would be difficult in priority update as it try to update ApplicationSubmissionContext. I think this is time to think for storing priority in ApplicaitonStateData. As I see storing priority as separate field in ApplicationStateData would be a difficult for priority update to change some of the implementation part especially during submission and recovery flow, but I think it is good to do it now. Thoughts?
# I see one race conditional bug since we are holding lock on applicationId. Could we do {{if (COMPLETED_APP_STATES.contains(application.getState())) {}} check either after holding lock of applicationId or in method {{RMStateStore#updateApplicationStateSynchronously}} ??
> Retrospect updateApplicationPriority api to handle state store exception in align with YARN-5611
> ------------------------------------------------------------------------------------------------
>
> Key: YARN-5865
> URL: https://issues.apache.org/jira/browse/YARN-5865
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Sunil G
> Assignee: Sunil G
> Attachments: YARN-5865.0001.patch
>
>
> Post YARN-5611, revisit dynamic update of application priority logic with respect to state store error handling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org