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

Abhishek Talluri commented on PHOENIX-4089:
-------------------------------------------

Steps to Reproduce:

Phoenix table has A,B,C,D,E as its columns and A as the primary key for the 
table.

CREATE TABLE TEST (A VARCHAR NOT NULL PRIMARY KEY, B VARCHAR, C VARCHAR, D 
VARCHAR , E VARCHAR);

Global index is built on D & E
CREATE INDEX TEST_IND on TEST (D,E);

Client 1 updates A,B,C whereas client 2 updates A,B,D,E

 

I used phoenix 5.14.2-1.cdh5.14.2.p0.3 parcel to test this issue. Ran with two 
threads that load data using upserts reading from the csv file. Within 10 
iterations, i could observe the difference in the row counts between data table 
and index table. Attaching the code used to test this behavior.

> 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
>            Priority: Major
>              Labels: secondary_index
>             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_v4.patch, PHOENIX_4089_v2.patch, PHOENIX_4089_v3.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
(v7.6.3#76005)

Reply via email to