phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4089) Prevent index from getting out of sync with data table under high concurrency
Date Thu, 17 Aug 2017 20:36:00 GMT

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

James Taylor commented on PHOENIX-4089:
---------------------------------------

[~tdsilva]
We still need Indexer.isProbablyClientControlledTimeStamp method because tests are still relying
on being able to use CURRENT_SCN for DML. I've filed PHOENIX-4096 to change that.

For UPSERT SELECT, since we keep the scanner open that's doing the SELECT, it won't see new
rows from the UPSERT. For example, the UpsertSelectAutoCommitIT.testUpsertSelectDoesntSeeUpsertedData
passes fine with this change. One potential caveat is if the region splits while the UPSERT
SELECT is running. I believe that fails today (see PHOENIX-3163 and PHOENIX-2903), but I've
filed PHOENIX-4097 to deal with that once these others are fixed.

> Prevent index from getting out of sync with data table under high concurrency
> -----------------------------------------------------------------------------
>
>                 Key: PHOENIX-4089
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4089
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>             Fix For: 4.12.0
>
>         Attachments: PHOENIX-4089_4.x-HBase-0.98.patch, PHOENIX-4089_4.x-HBase-0.98_v2.patch,
PHOENIX-4089_v1.patch, PHOENIX_4089_v2.patch, PHOENIX_4089_v3.patch, PHOENIX-4089_v4.patch
>
>
> Under high concurrency, we're still seeing the index get out of sync with the data table.
It seems that the particular case is when the same Put occurs with the same time stamp from
different clients, based on the locking we do, Phoenix thinks a different Put was the last
one than HBase does, leading to inconsistencies.
> The solution is to timestamp the cells on the server-side after the lock has been taken.
The new concurrent unit test passes 50x with this in place, while it otherwise fails 1/10
of the time (or more on HBase 1.3).



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

Mime
View raw message