Tsuyoshi OZAWA commented on YARN-2517:

[~zjshen], thanks for your comment.

// Async call - Type (1)
void asyncCall(Input, CallBackHandler);

If we choose Type(1), TimelineClient need to manage all objects of callback 
handlers it's passed. It can get more complex. I think it's better to add 
{{registerAsyncCallbackHandler(CallBackHandler)}} to add TimelineClient 
separately or pass the callback via constructor for the simplicity. Or, do we 
have use cases to switch CallBackHandler for each method calls?

Maybe compromise now is to add putEntitiesAsync to TimelineClient. In the 
future, let's see if we want to have a separate TimelineClientAsync that 
contains a bunch of async APIs.

If we will have a plan to migrate from putEntitiesAsync to TimelineClientAsync, 
I think we should add TimelineClientAsync from the beginning. I think it's 
enough to add *Async methods to current TimelineClient for now since users 
don't need to create specific clients for async calls.

[~mitdesai] thanks for your help. Looking forward to your opinion. We're 
discussing the design based on [Vinod's 

> Implement TimelineClientAsync
> -----------------------------
>                 Key: YARN-2517
>                 URL: https://issues.apache.org/jira/browse/YARN-2517
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Zhijie Shen
>            Assignee: Tsuyoshi OZAWA
>         Attachments: YARN-2517.1.patch, YARN-2517.2.patch
> In some scenarios, we'd like to put timeline entities in another thread no to 
> block the current one.
> It's good to have a TimelineClientAsync like AMRMClientAsync and 
> NMClientAsync. It can buffer entities, put them in a separate thread, and 
> have callback to handle the responses.

This message was sent by Atlassian JIRA

Reply via email to