[
https://issues.apache.org/jira/browse/YARN-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15649540#comment-15649540
]
Rohith Sharma K S commented on YARN-5611:
-----------------------------------------
[~sunilg]
bq 1. ApplicationClientProtocol#updateApplicationTimeouts .Could this be an
Evolving api?.
the API is already UnStable, I think should be fine. cc:/[~jianhe]
bq. 2. ApplicationClientProtocolPBClientImpl#updateApplicationTimeouts. Does
exception handling block needs return? RPCUtil method will throw exception,
correct?
bq. 3. In ApplicationClientProtocolPBServiceImpl#updateApplicationTimeouts, we
use catch (YarnException| IOException e).
frankly I just copy pasted from other API implementation from PBImpl. It looks
to be all API are doing the same way. If really want to clean, we can take
separate task to do refactoring PBClientImpl classes. Thoughts?
bq. 5. Given a writeLock in RMAppImpl#updateApplicationTimeout, why do we need
another lock in RMAppManager#updateApplicationTimeout. Is this to handle some
race conditions while app update event is waiting in StateStore dispatcher
queue? I would love to have some more comments in these synchronized blocks or
write locks to give a brief explanation. It will help us later
Good question!! Jian also had same doubt. Let me brief aobut it. Anything
holding writeLock in RMAppImpl blocks the main AsyncDiapatcher. This is costly
operation. For updateTimeout, we need to wait for transaction to complete which
can not be done holding RMAppImpl lock. So, in-memory updations happens from
RMAppImpl and trigger an event to StateStore and release the writeLock. Wait
for statestore update call from RMAppManager in separate lock.
bq. 4. On a different note, i think COMPLETED_APP_STATES could be defined by
RMAppImpl itself and expose a read-only api. This can help to cleanup local
states definitions. could be done in another patch.
I would prefer to do in separate JIRA. May be can you raise it?
bq. 6. RMApp is generally considered as read-only. updateApplicationTimeout
will violate that. we can place this api in RMAppImpl itself, and in client
side, we could convert to RMAppImpl object and use. ProportionPolicy, New
Global Scheduler etc are using this way.
I would prefer to add in RMApp itself rather than type casting in RMAppManager.
It is internal interface used for both read and write.
bq. 7. Timeout is to be part of ApplicationReport correct? Is that a part of
this patch?
this will be done in YARN-4206
> 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.0006.patch, YARN-5611.0007.patch, YARN-5611.0008.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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
