hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naganarasimha G R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3367) Replace starting a separate thread for post entity with event loop in TimelineClient
Date Thu, 24 Dec 2015 06:44:49 GMT

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

Naganarasimha G R commented on YARN-3367:

Thanks for the comments [~sjlee0],
bq. I would very much advocate using the JDK's ExecutorService (single-threaded executor in
this case) over using a raw thread and its own blocking queue management.
May be i dint get your thoughts completely but let me explain the reason i have taken this
approach, Some points what i have considered :
* We require all the events to be pushed in the order with which its submitted. Not sure whether
we require order to be maintained across sync and async events but definitely within sycn/
async its required based on the last [~djp]'s comment. (for ex:  metric events which are sent
as async requires to be order to ensure aggregation logic works properly and sync events like
container started / stopped so that state of it can be determined if there is any intermittent
daemon failures)
* As its single threaded better to merge the related events and push it once (like all the
waiting async events can be clubbed and pushed at once )
* for the Sync events we need to throw an exception on failure. so that caller is informed
that it failed.

Considering this i thought of maintaining a blocking queue and thread. so that  whenever the
data is available then code in the thread can take some action, (and by the time thread finishes
publishing and comes back to read the queue if multiple async entities are there it can merge
and publish in next round.).
May be the complexity will get reduced if we *need not maintain the order* across sync and
async events.
Or please inform if i increased the scope of the jira than what is required.
bq. On TimelineEntities.java,
Yep can incorporate those changes, i just relied on eclipse auto code generation for hash
and equals for a given class.

> Replace starting a separate thread for post entity with event loop in TimelineClient
> ------------------------------------------------------------------------------------
>                 Key: YARN-3367
>                 URL: https://issues.apache.org/jira/browse/YARN-3367
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Junping Du
>            Assignee: Naganarasimha G R
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-3367-feature-YARN-2928.003.patch, YARN-3367-feature-YARN-2928.v1.002.patch,
YARN-3367-feature-YARN-2928.v1.004.patch, YARN-3367.YARN-2928.001.patch
> Since YARN-3039, we add loop in TimelineClient to wait for collectorServiceAddress ready
before posting any entity. In consumer of  TimelineClient (like AM), we are starting a new
thread for each call to get rid of potential deadlock in main thread. This way has at least
3 major defects:
> 1. The consumer need some additional code to wrap a thread before calling putEntities()
in TimelineClient.
> 2. It cost many thread resources which is unnecessary.
> 3. The sequence of events could be out of order because each posting operation thread
get out of waiting loop randomly.
> We should have something like event loop in TimelineClient side, putEntities() only put
related entities into a queue of entities and a separated thread handle to deliver entities
in queue to collector via REST call.

This message was sent by Atlassian JIRA

View raw message