[
https://issues.apache.org/jira/browse/YARN-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125777#comment-14125777
]
Zhijie Shen commented on YARN-2517:
-----------------------------------
[~vinodkv], thanks for your feedback. The reason why an async client (or async
HTTP REST call) is going to be good is to unblock the current thread if it is
doing the important management logic. For example, in YARN-2033, we have a
bunch of logic to dispatch the entity putting action on a separate thread, to
make the application life cycle management move on. Given an async client, it
could be far more simplified. I think from the user point of view, it may be a
useful feature as well.
I'm fine whether we can two classes, sync for one and async for the other, or
one class for both modes, while the former option complies with the previous
client design. I think the callback is necessary, at least "onError".
TimelinePutResponse will give the user a summary of why his uploaded entity is
not accepted by the timeline server. Based on the response, the user can
determine whether the app should neglect the problem and move on, or stop
immediately.
> 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
>
>
> 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
(v6.3.4#6332)
