[ 
https://issues.apache.org/jira/browse/YARN-6896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120828#comment-16120828
 ] 

Giovanni Matteo Fumarola commented on YARN-6896:
------------------------------------------------

Thanks [~curino] for the feedback. I fixed the Yetus warnings.
1. I reused the same configuration to have the same behavior indifferently if 
the client is using RPC or REST. I can rename it or create a new one.
2. I updated that code. I created 2 new methods: create and get, and updated 
the current one with getOrCreate.
3. Updated by using the same blacklisting style of submitApp.
4. I kept in the description as a single javadoc block to avoid to be schematic.
5. Good point. If the application failed to be submitted after n retries, the 
tuple remains in the FederationStateStore. If the Client wants to resubmit the 
same application as its own retry logic, the Router will start from the current 
saved SubCluster in the StateStore. It could happen that the last SubCluster 
was down during the submission for failover.
However, that tuple in the StateStore is harmless. In future the application 
cleaner service we are implementing as part of YARN-6648 will clean up these 
tuples.
6. Good catch. Added also unit tests for that.
7. I implemented only the methods for the basic execution of an application - 
CreateNewApplication, SubmitApplication, GetAppReport, KillApplication. I 
updated the title to avoid confusion. We will add the other methods as part of 
YARN-6740.
8. I checked the code and we can save the part where we create the mock 
Federation subcluster in 2 test classes - few lines. However, moving that part 
will not optimize the code size since we are creating a new Util for these few 
lines. If the number of test classes will increase, we will move that piece of 
code and reuse it.
9. Removed one. I kept one to show that FederationInterceptorREST is 
independent from any "middle" interceptor.
10. Good point. I set the {{DefaultRequestInterceptorREST}} inside 
{{FederationInterceptorREST}} to be configurable. In this way in the future 
devs can add their own interceptors.


> Federation: routing REST invocations transparently to multiple RMs (part 1 - 
> basic execution)
> ---------------------------------------------------------------------------------------------
>
>                 Key: YARN-6896
>                 URL: https://issues.apache.org/jira/browse/YARN-6896
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Giovanni Matteo Fumarola
>            Assignee: Giovanni Matteo Fumarola
>         Attachments: YARN-6896.proto.patch, YARN-6896.v1.patch, 
> YARN-6896.v2.patch
>
>
> This JIRA tracks the design/implementation of the layer for routing 
> RMWebServicesProtocol requests to the appropriate RM(s) in a federated YARN 
> cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to