tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gopal V (JIRA)" <j...@apache.org>
Subject [jira] [Created] (TEZ-3974) Tez: Correctness regression of TEZ-955 in TEZ-2937
Date Wed, 01 Aug 2018 19:57:00 GMT
Gopal V created TEZ-3974:
----------------------------

             Summary: 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


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