tez-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TezQA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEZ-3974) Tez: Correctness regression of TEZ-955 in TEZ-2937
Date Thu, 09 Aug 2018 19:15:00 GMT

    [ 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)

Mime
View raw message