[ 
https://issues.apache.org/jira/browse/PHOENIX-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104261#comment-16104261
 ] 

Hadoop QA commented on PHOENIX-4051:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12879259/PHOENIX-4051_v1.patch
  against master branch at commit 9c458fa3d3ecdeb17de5b717c26cfdea1608c358.
  ATTACHMENT ID: 12879259

    {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:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
51 warning messages.

    {color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
     
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.hbase.index.covered.EndToEndCoveredColumnsIndexBuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ClientTimeArithmeticQueryIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1232//testReport/
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1232//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1232//console

This message is automatically generated.

> Prevent out-of-order updates for mutable index updates
> ------------------------------------------------------
>
>                 Key: PHOENIX-4051
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4051
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>         Attachments: PHOENIX-4051_v1.patch
>
>
> Out-of-order processing of data rows during index maintenance causes mutable 
> indexes to become out of sync with regard to the data table. Here's a simple 
> example to illustrate the issue:
> # Assume table T(K,V) and index X(V,K).
> # Upsert T(A, 1) at t10. Index updates: Put X(1,A) at t10.
> # Upsert T(A, 3) at t30. Index updates: Delete X(1,A) at t29, Put X(3,A) at 
> t30.
> # Upsert T(A,2) at t20. Index updates: Delete X(1,A) at t19, Put X(2,A) at 
> t20, Delete X(2,A) at t29
> Ideally, we'd want to remove the Delete X(1,A) at t29 since this isn't 
> correct in terms of timeline consistency, but we can't do that with HBase 
> without support for deleting/undoing Delete markers. 
> The above is not what is occurring. Instead, when T(A,2) comes in, the Put 
> X(2,A) will occur at t20, but the Delete won't occur. This causes more index 
> rows than data rows, essentially making it invalid.
> A quick fix is to reset the timestamp of the data table mutations to the 
> current time within the preBatchMutate call, when the row is exclusively 
> locked. This skirts the issue because then timestamps won't overlap.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to