[
https://issues.apache.org/jira/browse/PHOENIX-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029321#comment-17029321
]
Hadoop QA commented on PHOENIX-5708:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12992519/PHOENIX-5708.4.x-HBase-1.5.001.patch
against 4.x-HBase-1.5 branch at commit
b27168de1922d429229935b16eef49c00a88aab1.
ATTACHMENT ID: 12992519
{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:
+ indexTool = runIndexTool(directApi, useSnapshot, schemaName,
dataTableName, indexTableName, null,
+ assertEquals(NROWS,
indexTool.getJob().getCounters().findCounter(INPUT_RECORDS).getValue());
+ assertEquals(NROWS,
indexTool.getJob().getCounters().findCounter(SCANNED_DATA_ROW_COUNT).getValue());
+ assertEquals(0,
indexTool.getJob().getCounters().findCounter(REBUILT_INDEX_ROW_COUNT).getValue());
+ assertEquals(NROWS,
indexTool.getJob().getCounters().findCounter(BEFORE_REBUILD_VALID_INDEX_ROW_COUNT).getValue());
+ assertEquals(0,
indexTool.getJob().getCounters().findCounter(BEFORE_REBUILD_EXPIRED_INDEX_ROW_COUNT).getValue());
+ assertEquals(0,
indexTool.getJob().getCounters().findCounter(BEFORE_REBUILD_INVALID_INDEX_ROW_COUNT).getValue());
+ assertEquals(0,
indexTool.getJob().getCounters().findCounter(BEFORE_REBUILD_MISSING_INDEX_ROW_COUNT).getValue());
+ // 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);
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3383//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3383//console
This message is automatically generated.
> GlobalIndexChecker returns unverified index row cells
> -----------------------------------------------------
>
> Key: PHOENIX-5708
> URL: https://issues.apache.org/jira/browse/PHOENIX-5708
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 4.14.3
> Reporter: Kadir OZDEMIR
> Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5708.4.x-HBase-1.5.001.patch,
> PHOENIX-5708.master.001.patch, PHOENIX-5708.master.002.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation, unverified index row cells can be visible to
> clients. One scenario where this can happen is as follows. A client attempts
> to write a full data row but the data row write fails. This leaves an
> unverified index row corresponding to this data row. Later, the client
> attempts to write to the same row but this time it writes a partial data row
> such that one of the covered columns does not have a value in this partial
> write. After this, there will be two versions of the index row, the first one
> is unverified and the second one is verified. When the client reads the row
> back from the index table, since HBase will merge two versions of this index
> row, the client will get some cells from the unverified index row such that
> these cells are not in the verified index row. This is a bug. The fix is very
> simple. In GlobalIndexChecker, we need to remove the cells from the previous
> versions of the row. Please note that every index row is composed of cells
> with the same timestamp by design. By implementing this fix, we will ensure
> that this property always holds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
