You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2020/02/09 06:46:00 UTC

[jira] [Commented] (DRILL-7576) Fail fast in operators

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

ASF GitHub Bot commented on DRILL-7576:
---------------------------------------

paul-rogers commented on pull request #1975: DRILL-7576: Fail fast for operator errors
URL: https://github.com/apache/drill/pull/1975
 
 
   Converts operators to fail with a UserException rather than using
   the STOP iterator status. The result is clearer error messages
   and simpler code.
   
   ## Description
   
   Drill has long had two ways to indicate operator failures:
   
   * By throwing an unchecked exception, preferably `UserException`.
   * By setting the failed status on the operator and returning the `STOP` iterator status.
   
   Since the exception mechanism has been stable for several years, there is little reason to use the complex mechanism involved with the `STOP` status. Rather than write code to propagate `STOP` up the stack, we just let Java unwind the stack for us.
   
   This PR converts all places where we returned `STOP` status to instead throw an exception. It also cleans up some lingering places where lower-level calls threw generic exceptions to higher-level code. This PR catches the error as close as possible to the source of the error to allow clearer, more focused error messages.
   
   One consequence of using exceptions to report errors is that there is no longer any code to set the "failed" status for an operator. Mostly this doesn't matter; no code (except `STOP` handling) uses that status. Except in one place: the handy utility which dumps two batches on operator failure. That code relied on the failure status. Since most errors didn't set the status, the batch dump code did not actually work well.
   
   Instead of having each operator catch the exception and mark itself failed. this PR uses a more general solution. It compares the stack trace in the exception with the list of operators to determine the leaf-most operator. This must be the operator which failed. This operator, and its parent, are not those dumped by the batch dump code.
   
   ## Documentation
   
   This code is internal to Drill and is not user-visible.
   
   ## Testing
   
   Added a new test for the stack trace analyzer. Reran all unit tests and adjusted those that needed changes.
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Fail fast in operators
> ----------------------
>
>                 Key: DRILL-7576
>                 URL: https://issues.apache.org/jira/browse/DRILL-7576
>             Project: Apache Drill
>          Issue Type: Improvement
>    Affects Versions: 1.17.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>            Priority: Major
>             Fix For: 1.18.0
>
>
> Continues to the work to clean up operators to "fail fast" by throwing an exception instead of using the more involved STOP status.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)