[
https://issues.apache.org/jira/browse/YARN-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635311#comment-15635311
]
Rohith Sharma K S commented on YARN-5611:
-----------------------------------------
bq. 1. ApplicationUpdateTimeoutMapProto -> ApplicationUpdateTimeoutProto. May
not need to have "map" in the name of proto
It is naming convention I maintained with other map protos. Do not want to
change its naming convention.
bq. There is a any chance that NEW_SAVING could fail and app could no longer be
in next state. We could consider apps which are from ACCEPTED state, correct?
Any specific reason to consider NEW_SAVING?
Update timeout can also possible in NEW_SAVING state. This is because
state-store update is done from dispatcher queue which ensures that
updateTimeout event will go always behind new_saving event. So, should not be
problem updating in new_saving. In case, new_saving fails, then App it self is
failed.
bq. In validateISO8601AndConvertToLocalTimeEpoch, if (expireTime <
currentTimeMillis) helps to validate timeout's of past. But still there could
be a delta time from current time to next timeout check thread. Could that also
to be validated here? Or such entries will be discarded by the monitor thread?
When dealing with milliseconds, there will be delta changes. It should be fine.
Actually, as user I would expect to update timeout at least with 5minutes gap.
bq. In general thought and thinking out loud, Map<ApplicationTimeoutType, Long>
}} why we need a map here. Could we have {{List<ApplicationTimeouts> and each
ApplicationTimeouts could have its type and real timeout value in long. I am
not seeing much of benefit from map here as app timeout types could no be more
than 3/4 atmost.
Good question. There are couple of reason for considering MAP instead of List.
# It is defensive code style, where RM do not want to expect any duplicate
applicationTimeout types. If we go for List, user is allowed to input duplicate
timeout types so that RM server need to take decision which one to consider and
it is debatable topic. Advantage of is MAP is user send single timeout types.
It is more clarity for user as well as RM.
# Populating MAP is much easier in RM. In List, need to look up for all the
entry correspond to timeoutType. Let say, in new_saving, timeout update is for
LIFETIME. It is easier to look up and get value in map. But in list, on every
state need to iterate for all the values and find does LIFETIME exist or not.
> Provide an API to update lifetime of an application.
> ----------------------------------------------------
>
> Key: YARN-5611
> URL: https://issues.apache.org/jira/browse/YARN-5611
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Rohith Sharma K S
> Assignee: Rohith Sharma K S
> Labels: oct16-hard
> Attachments: 0001-YARN-5611.patch, 0002-YARN-5611.patch,
> 0003-YARN-5611.patch, YARN-5611.0004.patch, YARN-5611.0005.patch,
> YARN-5611.v0.patch
>
>
> YARN-4205 monitors an Lifetime of an applications is monitored if required.
> Add an client api to update lifetime of an application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
