You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Steven Phillips (JIRA)" <ji...@apache.org> on 2015/04/10 22:48:12 UTC

[jira] [Commented] (DRILL-2756) Check for cancellation in pseudo-blocking operations

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

Steven Phillips commented on DRILL-2756:
----------------------------------------

We do check for cancellation in AbstractRecordBatch.next(int inputIndex, RecordBatch b). I think this should be sufficient for most operators, including hash join and hash agg, since they work on a single incoming batch at a time, and one batch worth of work is shouldn't take that long.

The only one I think that needs special handling is ExternalSort, once all incoming batches have been received and there are no spills and we start the merge sort. This phase of the operation could take a long time, so we should do periodic checks while performing the sort.

> Check for cancellation in pseudo-blocking operations
> ----------------------------------------------------
>
>                 Key: DRILL-2756
>                 URL: https://issues.apache.org/jira/browse/DRILL-2756
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Relational Operators
>    Affects Versions: 0.8.0
>            Reporter: Chris Westin
>            Assignee: Chris Westin
>             Fix For: 0.9.0
>
>
> Certain operators, such as hash join, hash agg, and sort, consume all of their input before producing any output. For these, once they start working on their input, they don't check to see if the request has been cancelled. If another fragment fails (causing the overall query to be cancelled), or if the user requests a cancellation, these operators continue working because they never check.
> We need to add checks (e.g., ask FragmentContext.isCancelled() or something like that) to these at periodic points. We don't want to check after every row, but it should be checked every so often (mimicing other operations, which generally get notified at batch boundaries).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)