[
https://issues.apache.org/jira/browse/TEZ-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614003#comment-16614003
]
Kuhu Shukla commented on TEZ-3990:
----------------------------------
Hmm, so after some more offline discussion [~jeagles], this patch won't fully
address the issue specific to penalties and would cap the signaling to the AM,
which is not what we want.
To clarify, it is important to not allow for indefinite exponential growth on
penalties delay. It makes sending AM signals spaced out farther and makes it
difficult for the upstream to run and increases the overall runtime of the
downstream as well.
What we can instead do is cap the delay based on the value calculated and start
over with factor of one again to allow aggressive signaling or cap the delay at
that for all future occurrences to allow for debugging and provide constant
value function after one window of exponential growth per MapHost. Appreciate
more comments and I will post a revised (and hopefully a functional capping
mechanism) patch soon.
> The number of shuffle penalties for a host/inputAttemptIdentifier should be
> capped
> ----------------------------------------------------------------------------------
>
> Key: TEZ-3990
> URL: https://issues.apache.org/jira/browse/TEZ-3990
> Project: Apache Tez
> Issue Type: Bug
> Affects Versions: 0.9.1, 0.10.0
> Reporter: Kuhu Shukla
> Assignee: Kuhu Shukla
> Priority: Major
> Attachments: TEZ-3990.001.patch
>
>
> In a scenario where the same mapId fetches fail, the penalty code allows
> adding the same Host/InputAttemptIdentifier over and over with revised
> penalty time that grows exponentially. It should at some point drop the
> retrying and report failure to the AM asap to allow the job to rectify the
> upstream output.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
