[
https://issues.apache.org/jira/browse/YARN-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139177#comment-16139177
]
Giovanni Matteo Fumarola edited comment on YARN-7010 at 8/23/17 9:39 PM:
-------------------------------------------------------------------------
Thanks [~curino] for the feedback. Pushed v1.
2. Fixed.
3. I use CachedThreadPool. The size is not fixed, it creates new threads as
needed, but will reuse previously constructed threads when they are available
with LRU Cache system.This webiste explain the difference between them:
[Executors.newCachedThreadPool() versus Executors.newFixedThreadPool() |
https://stackoverflow.com/questions/949355/executors-newcachedthreadpool-versus-executors-newfixedthreadpool]
4. Fixed.
For 1. the fixed is not trivial. My current solution has the following behavior:
If one subcluster is down, I merge the reports I have by discarding the UAMs
without an AM.
To discriminate the UAM from the Federated ones I use size and name of the
applications.
If the size is greater than 1 it means the AM did spread in more than 1
subcluster. In this case the UAM is related to Federation -> Discarded.
If the size is 1 - it could be an simple UAM or an UAM depending from AMRMProxy
- and the name starts with the same convention we create the UAM inside
AMRMProxy, it means the UAM is related to Federation -> Discarded.
We kept otherwise.
was (Author: giovanni.fumarola):
Thanks [~curino] for the feedback. Pushed v1.
2. Fixed.
3. I use CachedThreadPool. The size is not fixed, it creates new threads as
needed, but will reuse previously constructed threads when they are available
with LRU Cache system.This webiste explain the difference between them:
[Executors.newCachedThreadPool() versus Executors.newFixedThreadPool() |
https://stackoverflow.com/questions/949355/executors-newcachedthreadpool-versus-executors-newfixedthreadpool]
4. Fixed.
For 1. the fixed is not trivial. My current solution has the following behavior:
If one subcluster is down, I merge the reports I have by discarding the UAMs
without an AM.
To discriminate the UAM from the Federated ones I use size and name of the
applications.
If the size is greater than 1 it means the AM spread in more than 1 subcluster
-> Discarded.
If the size is 1 - it could be an UAM or an UAM depending from AMRMProxy - If
the name starts with the same convention we create the UAM inside AMRMProxy ->
Discarded.
> Federation: routing REST invocations transparently to multiple RMs (part 2 -
> getApps)
> -------------------------------------------------------------------------------------
>
> Key: YARN-7010
> URL: https://issues.apache.org/jira/browse/YARN-7010
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Giovanni Matteo Fumarola
> Assignee: Giovanni Matteo Fumarola
> Attachments: YARN-7010.v0.patch, YARN-7010.v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
