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 Sat, 04 Aug 2018 02:49:00 GMT

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

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/12934359/TEZ-3974.1.patch
  against master revision fe22f32.

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified
tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler 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/2886//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2886//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-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