[
https://issues.apache.org/jira/browse/PHOENIX-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-4089:
----------------------------------
Attachment: PHOENIX-4089_v4.patch
Fixed test issue and removed unnecessary code. The code added for calling
buildIndex from the UpsertCompiler is not correct and not really a good idea.
We'd have to add such code after all DML statements and they'd potentially all
be partially building the index. That's what our catchup query in
MetaDataClient.buildIndex() is for. It was only not working before because we
were building the index synchronously in the coprocessor call and thus not
giving our catchup query a chance to work. Please review, [~tdsilva].
> 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)
