[
https://issues.apache.org/jira/browse/PHOENIX-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129529#comment-16129529
]
Hadoop QA commented on PHOENIX-4089:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12882188/PHOENIX_4089_v2.patch
against master branch at commit b13413614fef3cdb87233fd1543081e7198d685f.
ATTACHMENT ID: 12882188
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 15 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
56 warning messages.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ conn.createStatement().execute("CREATE TABLE " + tableName + "(k1
INTEGER NOT NULL, k2 INTEGER NOT NULL, v1 INTEGER, CONSTRAINT pk PRIMARY KEY
(k1,k2)) STORE_NULLS=true, VERSIONS=1");
+ conn.createStatement().execute("UPSERT INTO " +
tableName + " VALUES (" + (i % nRows) + ", 0, " + (isNull ? null : randInt) +
")");
+ conn.createStatement().execute("CREATE TABLE " + fullTableName +
"(k VARCHAR PRIMARY KEY, v VARCHAR) COLUMN_ENCODED_BYTES = 0,
STORE_NULLS=true");
+ conn.createStatement().execute("CREATE INDEX " + indexName + " ON
" + fullTableName + " (v)");
+ int count = conn.createStatement().executeUpdate("DELETE FROM " +
fullIndexName + " WHERE \":K\"='a' AND \"0:V\"='ccc'");
+ assertEquals(e.getMessage(),"Expected data table row count to
match expected:<2> but was:<1>");
+ conn.createStatement().execute("CREATE TABLE " + fullTableName +
"(k VARCHAR PRIMARY KEY, v VARCHAR, v2 VARCHAR) COLUMN_ENCODED_BYTES = 0,
STORE_NULLS=true");
+ conn.createStatement().execute("CREATE INDEX " + indexName + " ON
" + fullTableName + " (v) INCLUDE (v2)");
+ conn.createStatement().execute("UPSERT INTO " + fullTableName + "
VALUES('b','bb','0')");
+ conn.createStatement().execute("UPSERT INTO " + fullTableName + "
VALUES('a','ccc','1')");
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ScanQueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexToolForPartialBuildIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.ImmutableIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexToolForPartialBuildWithNamespaceEnabledIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.DistinctPrefixFilterIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1262//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1262//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1262//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1262//console
This message is automatically generated.
> 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
>
>
> 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)
