[jira] [Commented] (PHOENIX-2903) Handle split during scan for row key ordered aggregations

["Ethan Wang (JIRA)" <ji...@apache.org>]

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

Ethan Wang commented on PHOENIX-2903:
-------------------------------------

[~rajeshbabu]  [~jamestaylor], I was studying this patch, and I had some naive questions regarding how BaseResultIterators#getIterators handles NSRE. Thanks!

Seems to me that, when all completable futures come back, if one scanner turn out to be unsuccessful (NSRE), it will recursively calls getIterators which again try to ask coprocessor to create this scanner based on the start and end rowkey from the failed scan. This recursion will eventually finish when all scanner is created and packed into "iterators" and return back. Is this correct?

My question is, What if a split that happens after the entire process above finishes (iterators created, but before .next() is called). The scanner objects that impacted by this split will be essentially lost. Is this situation possible?


> Handle split during scan for row key ordered aggregations
> ---------------------------------------------------------
>
>                 Key: PHOENIX-2903
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2903
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>             Fix For: 4.12.0
>
>         Attachments: PHOENIX-2903_v1.patch, PHOENIX-2903_v2.patch, PHOENIX-2903_v3.patch, PHOENIX-2903_v4_wip.patch, PHOENIX-2903_v5_wip.patch, PHOENIX-2903_wip.patch
>
>
> Currently a hole in our split detection code



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)