drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-6098) Make Drill Failure Handling Consistent
Date Fri, 19 Jan 2018 01:59:00 GMT

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

Paul Rogers commented on DRILL-6098:

Thanks for taking on this task! Posted a design document from an earlier attempt in case if
offers any useful ideas.

> Make Drill Failure Handling Consistent
> --------------------------------------
>                 Key: DRILL-6098
>                 URL: https://issues.apache.org/jira/browse/DRILL-6098
>             Project: Apache Drill
>          Issue Type: Improvement
>            Reporter: Timothy Farkas
>            Assignee: Timothy Farkas
>            Priority: Major
>         Attachments: Drill Operator Error Handling Redesign.pdf
> As described by [~Paul.Rogers]
> "
> We have multiple ways of reporting errors:
>  * Throw a UserException explaining the error
>  * Throw an unchecked exception and and let the fragment executor guess the cause.
>  * Return STOP
>  * Tell the fragment executor to fail. (A we also required to return STOP?)
>  * Return OUT_OF_MEMORY status
> The proposal is to replace them all with a single solution: throw a UserException. Each
operator catches other exceptions and translates them to UserException.
> Java unwinds the stack just fine; no reason for us to write code to do it via STOP.
> Then, the Fragment Executor calls close() on all operators. No reason to try to do this
cleanup on STOP. (Even if we do, the lower-level operators won't have seen the STOP.)
> Since failures are hard to test, and have cause no end of problems, having multiple ways
to do the same thing is really not that helpful to Drill users.
> "

This message was sent by Atlassian JIRA

View raw message