[
https://issues.apache.org/jira/browse/PHOENIX-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041402#comment-17041402
]
Hadoop QA commented on PHOENIX-5743:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12994037/PHOENIX-5743.master.001.patch
against master branch at commit 28de55b5c79a5fc32dee97a59e5b4f528ca6dce6.
ATTACHMENT ID: 12994037
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ // No need to run the same test twice one for async = true and
the other for async = false
+ " (id varchar(10) not null primary key, val1 varchar(10),
val2 varchar(10), val3 varchar(10))" + tableDDLOptions);
+ conn.createStatement().execute("upsert into " + dataTableName + "
(id, val1, val2) values ('a', 'ab','abc')");
+ conn.createStatement().execute("upsert into " + dataTableName + "
values ('a', 'ab','abc', 'abcd')");
+ conn.createStatement().execute("upsert into " + dataTableName + "
(id, val1, val2) values ('a', 'ab','abc')");
+
del.addFamilyVersion(indexMaintainer.getEmptyKeyValueFamily().copyBytesIfNecessary(),
ts);
+
del.addFamily(indexMaintainer.getEmptyKeyValueFamily().copyBytesIfNecessary(),
ts);
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexRebuildTaskIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3467//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3467//console
This message is automatically generated.
> Concurrent read repairs on the same index row should be idempotent
> ------------------------------------------------------------------
>
> Key: PHOENIX-5743
> URL: https://issues.apache.org/jira/browse/PHOENIX-5743
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 4.14.3
> Reporter: Kadir OZDEMIR
> Assignee: Kadir OZDEMIR
> Priority: Critical
> Attachments: PHOENIX-5743.4.x-HBase-1.3.001.patch,
> PHOENIX-5743.master.001.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is possible that two or more read repairs can work on the same row.
> Regardless of how many read repairs concurrently happen on this row, the end
> result should be the same. The current implementation does not satisfy this
> property in one case. This can happen with the following steps:
> # An update on a data table row fails due to the data table row write
> failure (the phase two write). Since the phase 1 (unverified index write) has
> completed here, this leaves an unverified row in the index table.
> # Two (or more) concurrent queries on this table scans this unverified index
> row.
> # Each query triggers a separate read repair activity.
> # The first one deletes the unverified row correctly.
> # The subsequent ones may leave a wrong delete marker which corrupts this
> index row.
> Step 5 can happen because of two bugs in deleteRowIfAgedEnough() in
> GlobalIndexChecker.GlobalIndexScanner:
> # "deleteRowScan.setTimeRange(0, ts + 1);" should read
> "deleteRowScan.setTimeRange(ts, ts + 1);". This will make sure that the first
> read repair will retrieve the cells of the unverified row with the timestamp
> ts but the subsequent read repair gets either the same set of cells the first
> one got, or no cell (i.e., empty row).
> # If the unverified row has been already deleted, deleteRowIfAgedEnough()
> should do nothing and return. However, the current implementation either the
> read repair will retrieve the previous row version (i.e., previous to the
> unverified row) and leaves DeleteColumn markers for wrong cells, or it will
> get no cells (if no previous row version exists) and leaves a DeleteFamily
> marker which will deletes all previous versions of the row if such rows are
> inserted back by index rebuild.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
