Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Wed, 16 Aug 2017 15:45:00 +0000 (UTC)
From: "James Taylor (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13095057.1502898278000.44670.1502898300695@Atlassian.JIRA>
In-Reply-To: <JIRA.13095057.1502898278000@Atlassian.JIRA>
References: <JIRA.13095057.1502898278000@Atlassian.JIRA> <JIRA.13095057.1502898278132@jira-lw-us.apache.org>
Subject: [jira] [Created] (PHOENIX-4089) Prevent index from getting out of
 sync with data table under high concurrency
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 16 Aug 2017 15:45:08 -0000

James Taylor created PHOENIX-4089:
-------------------------------------

             Summary: 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


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)