[
https://issues.apache.org/jira/browse/TEZ-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956381#comment-14956381
]
Rajesh Balamohan commented on TEZ-2888:
---------------------------------------
TaskAttemptInfo::getPostDataExecutionTimeInterval - getLastDataEvents() is
already sorted in asc order. So it should be fine to directly check for
getLastDataEvents().size()-1.
In CriticalPathAnalyzer, maxConcurrency is determined at the DAG level. But it
is quite possible that the initial concurrency was low and gradually it got
more containers. Would the following code break in such cases?
{noformat}
int numVertexTasks = attempt.getTaskInfo().getVertexInfo().getNumTasks();
double numWaves = (numVertexTasks*1.0) / maxConcurrency;
{noformat}
concurrencyByTime is populated, but considered for later use?. Tooltip/Notes
section could be populated with concurrency details?
Rest looks good to me.
> Make critical path calculation resilient to AM crash
> ----------------------------------------------------
>
> Key: TEZ-2888
> URL: https://issues.apache.org/jira/browse/TEZ-2888
> Project: Apache Tez
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Bikas Saha
> Attachments: TEZ-2888.1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
