[
https://issues.apache.org/jira/browse/YARN-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naganarasimha G R updated YARN-3367:
------------------------------------
Attachment: YARN-3367-YARN-2928.v1.008.patch
Thanks [~sjlee0] for the comments,
* *checkstyle violations & whitespace* : have corrected where ever possible and
few will get corrected when i extract Timeline client V2impl
* {{TestTimelineClientV2Impl#testSyncCall}} is relevant. have corrected it and
run multiple times locally and its passing for me now.
* *TestDistributedShell* : This seems to be strange, is there any way to get
the actual test class log from the machine. as its failing abruptly will not
be able to analyze with the limited information. Me and [~varun_saxena] have
run multiple times locally to verify it. And similar exception is seen for
{{TestUberAM}}, there might be some issue but not sure how to trace it ! any
idea?
bq. I agree it may be a good idea to create separate implementation classes for
v.1 and v.2, but I would prefer if we defer it till the end. We had a fair
share of rebase challenges due to refactoring of SystemMetricsPublisher. The
refactoring itself was good and very much needed, but it just had an unintended
consequence of complicating rebase.
Though we will be extracting only the newly added code even i would not suggest
to burden the load of rebase. My thoughts was after this jira i will spawn a
new jira and do the modifications there and we can get that committed after the
last rebase.
> 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-YARN-2928.v1.005.patch,
> YARN-3367-YARN-2928.v1.006.patch, YARN-3367-YARN-2928.v1.007.patch,
> YARN-3367-YARN-2928.v1.008.patch, 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,
> sjlee-suggestion.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
(v6.3.4#6332)
