Zhijie Shen commented on YARN-3034:

bq. Whether we require Multithreaded Dispatcher as we are not publishing 
container life cycle events and if normal dispatcher is ok whether to use 
rmcontext.getDispatcher ?

Previously, the reason why we use a separate dispatcher instead of the 
rmcontext dispatcher is that we want to make sure the timeline service I/O 
operations may not block the normal app life cycle management. The 
multi-threaded dispatcher is designed to increase concurrency.

If aggregator is able to handle the requests in the async way, I'm okay to use 
rmcontext dispatcher. Otherwise, let's make sure at least we're using a 
separate async dispatcher.

bq. How is it today with the current ATS?

Currently, we don't have any special app/attempt/container entity. They're the 
payload of entity objects. I think it makes sense to have the special 
app/attempt/container entity for next gen, because given these are first class 
citizen and predefined, we have more chance to do the storage level 
optimization for them, instead of treating them generally. Thoughts?

To Naga's question, I suggest that app, attempt and container are all entities 
instead of being events of the parent entity. Logically attempt or container is 
the sub-component within an app, and has it's related events.

> implement RM starting its ATS writer
> ------------------------------------
>                 Key: YARN-3034
>                 URL: https://issues.apache.org/jira/browse/YARN-3034
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Naganarasimha G R
>         Attachments: YARN-3034.20150205-1.patch
> Per design in YARN-2928, implement resource managers starting their own ATS 
> writers.

This message was sent by Atlassian JIRA

Reply via email to