[
https://issues.apache.org/jira/browse/PHOENIX-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-4144:
----------------------------------
Attachment: PHOENIX-4144_wip_v2.patch
Actually, I'm not able to repro it. My original repro had an error in the way
it was manipulating its clock. The
INDEX_FAILURE_HANDLING_REBUILD_OVERLAP_FORWARD_TIME_ATTRIB which is the overlap
between when an index is marked INACTIVE versus when the rebuilder starts (by
default 180000ms) should be long enough to prevent this. Maybe if a client is
stuck in an HBase retry loop for a long time (where the client has the index
marked as disabled), this could occur. If that's the case, then I'm not sure
how we can prevent it. Maybe Phoenix needs to manage the retry loops. If a
client writes to the table while the index is disabled *after* the index
builder is finished, then the index can get out of sync.
Maybe we can leave the index active and let the write be attempted every time.
> Query for latest version during index rebuilding
> ------------------------------------------------
>
> Key: PHOENIX-4144
> URL: https://issues.apache.org/jira/browse/PHOENIX-4144
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Attachments: PHOENIX-4144_wip.patch, PHOENIX-4144_wip_v2.patch
>
>
> We're currently setting an upper bound of the scan to find the previous data
> table row when rebuilding the index. We need to remove this upper bound,
> though, so that we know if there are more recent versions of a data table row
> so that we delete the row we've added. We can then process one row past our
> current timestamp so we don't miss any deletes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
