[
https://issues.apache.org/jira/browse/PHOENIX-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090795#comment-16090795
]
Samarth Jain commented on PHOENIX-4026:
---------------------------------------
Talked to [~jamestaylor] offline and I see now what the race condition is. By
making the doPost (which writes the index updates) asynchronous, we are likely
completing our doMiniBatchMutation() operation without knowing whether the
index updates will be successfully written or not.
{code}
doMiniBatchMutation(batchOp);
long newSize = this.getMemstoreSize();
if (isFlushSize(newSize)) {
requestFlush();
}
{code}
After doMiniBatchMutation completes, we end up potentially flushing the
memstore to an HFile. If we end up flushing, the corresponding edits in WAL
file would be ignored when recovery starts after a region server crash. Because
we share the data table WAL for index and data table updates, the recovery
process will also skip the index edits. This is not good because if the region
server crashed with doPost() working in background, then we probably didn't get
the chance to mark the index as disabled either. So now at this point we won't
have WAL edits to fall back and the index rebuild task won't kick off either to
reenable the index.
> Option to not wait on global mutable index write to complete
> ------------------------------------------------------------
>
> Key: PHOENIX-4026
> URL: https://issues.apache.org/jira/browse/PHOENIX-4026
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Attachments: PHOENIX-4026_wip.patch
>
>
> Today, a data table update synchronously waits for the index update to
> complete. While some users may want that kind of strong consistency, some may
> be ok with the call to return once the data table write is done.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
