[
https://issues.apache.org/jira/browse/YARN-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315265#comment-14315265
]
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
(v6.3.4#6332)
