[
https://issues.apache.org/jira/browse/PHOENIX-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960150#comment-16960150
]
Hadoop QA commented on PHOENIX-5539:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12984047/PHOENIX-5539.master.003.patch
against master branch at commit 6063dcbb52d371d008b44169eae4fe9d43dfb95c.
ATTACHMENT ID: 12984047
{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:
+ public static void checkUnverifiedCellCount(Connection conn, String
indexTableName) throws Exception {
+ assertEquals(true, verifyRowsForEmptyColValue(conn, indexTableName,
IndexRegionObserver.UNVERIFIED_BYTES));
+ " (id varchar(10) not null primary key, val1 varchar(10),
val2 varchar(10), val3 varchar(10))" + tableDDLOptions);
+ // Configure IndexRegionObserver to fail the last write phase
(i.e., the post index update phase)
+ conn.createStatement().execute("upsert into " + dataTableName + "
(id, val2) values ('a', 'abcc')");
+ if (Bytes.compareTo(cell.getQualifierArray(),
cell.getQualifierOffset(), cell.getQualifierLength(),
+ Collection<? extends Mutation> mutations,
long now) throws Throwable {
+ // Remove the empty column prepared by Index codec
as we need to change its value
+ // For this mutation whether it is put or delete, set
the status of the index row "unverified"
+ // This will be done before the data table row is
updated (i.e., in the first write phase)
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.PermissionsCacheIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3069//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3069//console
This message is automatically generated.
> Full row index write at the last write phase for mutable global indexes
> -----------------------------------------------------------------------
>
> Key: PHOENIX-5539
> URL: https://issues.apache.org/jira/browse/PHOENIX-5539
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.0.0, 4.15.0
> Reporter: Kadir OZDEMIR
> Assignee: Kadir OZDEMIR
> Priority: Major
> Attachments: PHOENIX-5539.master.001.patch,
> PHOENIX-5539.master.002.patch, PHOENIX-5539.master.003.patch,
> PHOENIX-5539.master.004.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> In the original design for consistent indexes, we do three phase write. In
> the first phase, we write full index rows with unverified status, then we
> write data table rows, and finally we overwrite the index row status on the
> rows written at the first phase and set it to unverified.
> Instead of writing full index row in the first phase, we can do full index
> row write at the last phase. So, in the first phase, we can just write
> unverified status for the index row. In the last row, we can do full row
> index write at the last phase.
> This change does not impact the correctness of the design but improves
> overall design in terms of efficiency. In the presence of concurrent writes,
> we skip the last write phase. These writes leave the index writes in
> unverified status. Similarly, if the first or second phase write fails, we do
> not proceed with the third phase.
> Since with this change, we will be writing only the empty column with the
> unverified status value (i.e., 2) for index tables in these failure cases,
> the storage usage will be improved as we will write less index data. This
> change also opens up the solution domain for some problems, e.g., handling
> replication lag issues (please see PHOENIX-5527).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
