[
https://issues.apache.org/jira/browse/TEZ-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575281#comment-16575281
]
TezQA commented on TEZ-3974:
----------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12935012/TEZ-3974.3.patch
against master revision fe22f32.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:red}-1 javac{color}. The applied patch generated 179 javac
compiler warnings (more than the master's current 177 warnings).
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 3.0.1) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-TEZ-Build/2889//testReport/
Javac warnings:
https://builds.apache.org/job/PreCommit-TEZ-Build/2889//artifact/patchprocess/diffJavacWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2889//console
This message is automatically generated.
> Tez: Correctness regression of TEZ-955 in TEZ-2937
> --------------------------------------------------
>
> Key: TEZ-3974
> URL: https://issues.apache.org/jira/browse/TEZ-3974
> Project: Apache Tez
> Issue Type: Bug
> Reporter: Gopal V
> Assignee: Jaume M
> Priority: Critical
> Attachments: TEZ-3974.1.patch, TEZ-3974.2.patch, TEZ-3974.3.patch
>
>
> TEZ-2937 might have introduced a race condition for Tez output events, along
> with TEZ-2237
> {code}
> // Close the Outputs.
> for (OutputSpec outputSpec : outputSpecs) {
> String destVertexName = outputSpec.getDestinationVertexName();
> initializedOutputs.remove(destVertexName);
> List<Event> closeOutputEvents =
> ((LogicalOutputFrameworkInterface)outputsMap.get(destVertexName)).close();
> sendTaskGeneratedEvents(closeOutputEvents,
> EventProducerConsumerType.OUTPUT, taskSpec.getVertexName(),
> destVertexName, taskSpec.getTaskAttemptID());
> }
> // Close the Processor.
> processorClosed = true;
> processor.close();
> {code}
> As part of TEZ-2237, the outputs send empty events when the output is closed
> without being started (which happens in task init failures).
> These events are obsoleted when a task fails and this happens in the AM, but
> not before the dispatcher looks at them.
> Depending on the timing, the empty events can escape obsoletion & be sent to
> a downstream task.
> This gets marked as a SKIPPED event in the downstream task, which means that
> further obsoletion events sent to the downstream task is ignored (because a
> zero byte fetch is not repeated on node failure).
> So the downstream task can exit without actually waiting for the retry of the
> failed task and cause silent dataloss in case where the retry succeeds in
> another attempt.
> So if processor.close() throws an exception, this introduce a race condition
> and if the AM is too fast, we end up with correctness issues.
> This was originally reported in TEZ-955
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
