[
https://issues.apache.org/jira/browse/YARN-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913770#comment-13913770
]
Naren Koneru commented on YARN-1577:
------------------------------------
Agreed that when people use UnmanagedAMLauncher, the change can be hidden.
However, in some cases, we dont use this class since we dont necessarily spawn
a process for AM in the unmanaged client always. I am ok to break compatibility
for this use case and we can fix the UnmanagedAMLauncher to wait till the
attempt is launched.
As for the hack you mentioned, though that solution seems to be the least
intrusive, I am a little skeptical if this would have any side effects since we
would be lying in the ApplicationClientProtocol. Otherwise, we can get the
changes from YARN-1389 and change the UnmanagedAMLauncher and the llama clients
accordingly.
thoughts??..I am ok with either approach.
> Unmanaged AM is broken because of YARN-1493
> -------------------------------------------
>
> Key: YARN-1577
> URL: https://issues.apache.org/jira/browse/YARN-1577
> Project: Hadoop YARN
> Issue Type: Sub-task
> Affects Versions: 2.3.0
> Reporter: Jian He
> Assignee: Naren Koneru
> Priority: Blocker
>
> Today unmanaged AM client is waiting for app state to be Accepted to launch
> the AM. This is broken since we changed in YARN-1493 to start the attempt
> after the application is Accepted. We may need to introduce an attempt state
> report that client can rely on to query the attempt state and choose to
> launch the unmanaged AM.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
