Differences between revisions 5 and 6
Revision 5 as of 2008-12-23 23:57:34
Size: 7318
Comment:
Revision 6 as of 2009-09-20 23:38:19
Size: 7334
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
[[Navigation(children)]]
[[TableOfContents]]
<<Navigation(children)>>
<<TableOfContents>>
Line 7: Line 7:
This document describes the design for the error handling feature in Pig. The design follows the [#errReq requirements] and [#errFuncSpec functional specification]. The error handling design is influenced by Mika Raento's excellent online [#mika resource]. This document describes the design for the error handling feature in Pig. The design follows the [[#errReq|requirements]] and [[#errFuncSpec|functional specification]]. The error handling design is influenced by Mika Raento's excellent online [[#mika|resource]].
Line 9: Line 9:
Pig's architecture is designed to support several back-ends. Currently, the only supported back-end is Hadoop. The front-end is ideally back-end agnostic. For a breakdown of the front-end components refer to the [#errFuncSpec functional specification]. Pig's architecture is designed to support several back-ends. Currently, the only supported back-end is Hadoop. The front-end is ideally back-end agnostic. For a breakdown of the front-end components refer to the [[#errFuncSpec|functional specification]].
Line 17: Line 17:
attachment:PigException.jpg {{attachment:PigException.jpg}}
Line 71: Line 71:
attachment:PigLogger.jpg {{attachment:PigLogger.jpg}}
Line 100: Line 100:
 1. [[Anchor(errReq)]] Santhosh Srinivasan, Pig Error Handling Requirements October 30, 2008, http://wiki.apache.org/pig/PigErrorHandling
 2. [[Anchor(errFuncSpec)]] Santhosh Srinivasan, Pig Error Handling Functional Specification, December 8, 2008, http://wiki.apache.org/pig/PigErrorHandlingFunctionalSpecification
 3. [[Anchor(mika)]] Mika Raento, "What should Exceptions look like?" July 30, 2006, http://www.errorhandling.org/wordpress/
 1. <<Anchor(errReq)>> Santhosh Srinivasan, Pig Error Handling Requirements October 30, 2008, http://wiki.apache.org/pig/PigErrorHandling
 2. <<Anchor(errFuncSpec)>> Santhosh Srinivasan, Pig Error Handling Functional Specification, December 8, 2008, http://wiki.apache.org/pig/PigErrorHandlingFunctionalSpecification
 3. <<Anchor(mika)>> Mika Raento, "What should Exceptions look like?" July 30, 2006, http://www.errorhandling.org/wordpress/

This document describes the design for the error handling feature in Pig. The design follows the requirements and functional specification. The error handling design is influenced by Mika Raento's excellent online resource.

Pig's architecture is designed to support several back-ends. Currently, the only supported back-end is Hadoop. The front-end is ideally back-end agnostic. For a breakdown of the front-end components refer to the functional specification.

Error Handling

Front-end

PigException will serve as the base class for all the frontend exceptions. PigException will also be the exception thrown by Pig to external systems. Presently, the Pig APIs throw IOException. As a result, PigException will extend IOException in order to maintain backward compatibility. FrontendException will extend PigException and serve as the umbrella for all front-end exceptions. The task specific exceptions from the front-end components will subclass FrontendException to ensure clarity and enable extensions in the future.

PigException.jpg

PigException contains the following attributes and methods.

Attributes

  1. retriable: A boolean variable to indicate if an exception is retriable or not
  2. errorSouce: An enum to represent the source of the error. The enum can be extended in the future to include more information like sub-component. The values for this enum type will be:
    1. User input
    2. Bug
    3. User environment
    4. Remote environment
  3. errorCode: An integer that represents the error. Used for documentation and automation
  4. detailedMsg: A string that holds detailed information that is pertinent to the Pig developer. It will contain details that are not required by the user

Methods

  1. retirable: Return true if the exception is retirable; false otherwise
  2. getErrorCode: Returns the error code associated with this exception
  3. getDetailedMessage: Returns the string detailedMsg

Methods of interest from IOException and its super classes

  1. getMessage: User facing message will be reported using getMessage()
  2. getCause: When exceptions are chained, the cause of each exception is retrieved using getCause()
  3. getStackTrace: Useful for determining the root cause and contains details required by the developer
  4. initCause: Used for chaining exceptions

As mentioned earlier, the source of the exception is classified into the four categories. Each exception should report the appropriate source based on the context. Absence of the source will be treated as a bug by default.

Back-end

  • Hadoop reports errors via strings instead of exceptions. Since Hadoop does not support any APIs to query the exception thrown, Pig will make an assumption on the format of the string. The error messages contain the string format of an exception, i.e., name of the exception along with an error message followed by the stack trace. Pig will parse these error messages and report the appropriate error message and source (i.e., stack trace). An example of an error string reported by Hadoop is shown below. The distinction between a Hadoop error versus a Pig error will be made by looking for the source in the first element of the stack trace.

   1 java.lang.RuntimeException: Unexpected data type 74 found in stream.                                                   
   2         at org.apache.pig.data.DataReaderWriter.readDatum(DataReaderWriter.java:115)
   3         at org.apache.pig.builtin.BinStorage.bytesToInteger(BinStorage.java:169)
   4         at org.apache.pig.backend.hadoop.executionengine.physicalLayer.expressionOperators.POCast.getNext(POCast.java:143)
   5         at org.apache.pig.backend.hadoop.executionengine.physicalLayer.relationalOperators.POForEach.processPlan(POForEach.java:242)
   6         at org.apache.pig.backend.hadoop.executionengine.physicalLayer.relationalOperators.POForEach.getNext(POForEach.java:180)
   7         at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.runPipeline(PigMapBase.java:170)
   8         at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:158)
   9         at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapOnly$Map.map(PigMapOnly.java:65)
  10         at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:47)
  11         at org.apache.hadoop.mapred.MapTask.run(MapTask.java:227)
  12         at org.apache.hadoop.mapred.TaskTracker$Child.main(TaskTracker.java:2207)                              
  • Hadoop reports multiple failures due to retries. The retries have to be ignored and only the final failure has to be reported. The number of retries will be reported.

Warning message aggregation

Back-end

Hadoop provides the ability to aggregate counters for the entire application. The change in counter values has to be performed via the Hadoop reporter. A new interface, PigLogger will be used to abstract logging of warning messages. A back-end specific PigHadoopLogger will implement this interface and provide the functionality of warning message aggregation using Hadoop counters if the warning message aggregation is turned on. The EvalFunc class will include a new PigHadoopLogger attribute to allow UDF authors to log and aggregate warning messages. The key for the warning aggregation will be one of many pre-defined keys in Pig. If the warning message aggregation is turned off, the warning messages are sent to STDERR which will appear in Hadoop's STDERR logs.

PigLogger.jpg

   1 ...
   2 public abstract class EvalFunc<T>  {
   3     // UDFs must use this to report progress
   4     // if the exec is taking more that 300 ms
   5     protected PigProgressable reporter;
   6    
   7     // UDFs must use this to log and aggregate
   8     // warning messages
   9     protected PigHadoopLogger log;
  10 ...
  11 }

Front-end

Currently, the type checker uses a collector to collect error and warning messages. The use of the collector has to be extended for each subsystem in the front-end.

Open questions

  1. ParseException is throw by the parser. Ensuring that ParseException is subclassed from FrontendException requires the generated ParseException.java file to be checked into the source repository. Instead, the ParseException is wrapped inside FrontendParseException and rethrown.

  2. Lexical errors in Grunt will result in a TokenMgrError, resulting in a possible exit from Grunt.

  3. Error messages reported by the Parser will not be overridden with custom error messages till we move to a bottom up parser.

References

  1. Santhosh Srinivasan, Pig Error Handling Requirements October 30, 2008, http://wiki.apache.org/pig/PigErrorHandling

  2. Santhosh Srinivasan, Pig Error Handling Functional Specification, December 8, 2008, http://wiki.apache.org/pig/PigErrorHandlingFunctionalSpecification

  3. Mika Raento, "What should Exceptions look like?" July 30, 2006, http://www.errorhandling.org/wordpress/

PigErrorHandlingDesign (last edited 2009-09-20 23:38:19 by localhost)