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

Naganarasimha G R commented on YARN-3367:
-----------------------------------------

Thanks [~sjlee0], for sharing these points:
bq.  First of all, is it fair to assume that a TimelineClient belongs to a 
single user for the duration of the client? 
Even i was little skeptical about it, hence did not take a call there. But IMO 
if its used by *AM* or a *Container* then i think it would be safe to assume 
that its only used by a single UGI, as security Tokens needs to be got by the 
client from ATS server and then send it as part of launch context. So ideally 
single UGI is used for a timeline client but currently there is no restriction, 
but may be we can document the same.
bq.  If the former, then possibly we could pass in the UGI to the constructor 
so that the actual calls are made under doAs().
Based on above thoughts i think most propable solution is this.
bq.  combining entities into a single call becomes immediately complicated. In 
that case, we probably shouldn't combine entities from different users.
Good point, did not think about this ! If we conclude as multiple UGI can use 
the same Timeline Client then we need to merge Entities only if the UGI is same 
(because this would be the most common use case). Further to avoid this 
disadvantage i would prefer to use single UGI by each timeline client. Thoughts?

> 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-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
(v6.3.4#6332)

Reply via email to