phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ethan Wang (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-2903) Handle split during scan for row key ordered aggregations
Date Fri, 22 Sep 2017 07:36:00 GMT


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:
>             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

View raw message