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

Hadoop QA commented on PHOENIX-5645:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12990937/PHOENIX-5645-4.14-HBase-1.4.patch
  against 4.14-HBase-1.4 branch at commit 
208509b2ee18699d18bc623d2f09d38b7b298a09.
  ATTACHMENT ID: 12990937

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:green}+1 tests included{color}.  The patch appears to include 4 new 
or modified tests.

    {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:
    +        
props.put(QueryServices.GLOBAL_INDEX_ROW_AGE_THRESHOLD_TO_DELETE_MS_ATTRIB, 
Long.toString(0));
+        props.put(ScanInfoUtil.PHOENIX_MAX_LOOKBACK_AGE_CONF_KEY, 
Integer.toString(MAX_LOOKBACK_AGE));
+            assertRowHasExpectedValueAtSCN(getUrl(), dataTableSelectSql, 
afterInsertSCN, firstValue);
+            assertRowHasExpectedValueAtSCN(getUrl(), indexTableSelectSql, 
afterInsertSCN, firstValue);
+        while ((lastCompactionTimestamp = 
admin.getLastMajorCompactionTimestamp(table)) < compactionRequestedSCN
+            conn.createStatement().execute("upsert into " + tableName + " 
values ('a', 'ab', 'abc', 'abcd')");
+            conn.createStatement().execute("upsert into " + tableName + " 
values ('b', 'bc', 'bcd', 'bcde')");
+                                         String dataTableFullName, String 
indexTableFullName) throws SQLException {
+        IndexToolIT.assertExplainPlan(false, actualExplainPlan, 
dataTableFullName, indexTableFullName);
+        populateTable(dataTableName); // with two rows ('a', 'ab', 'abc', 
'abcd') and ('b', 'bc', 'bcd', 'bcde')

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
     
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexToolIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.SaltedIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexScrutinyToolIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3302//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3302//console

This message is automatically generated.

> BaseScannerRegionObserver should prevent compaction from purging very 
> recently deleted cells
> --------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5645
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5645
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>         Attachments: PHOENIX-5645-4.14-HBase-1.4.patch, 
> PHOENIX-5645-4.x-HBase-1.5-v2.patch, PHOENIX-5645-4.x-HBase-1.5.patch, 
> PHOENIX-5645-4.x-HBase-1.5.v3.patch, PHOENIX-5645-addendum-4.x-HBase-1.5.patch
>
>          Time Spent: 9h 40m
>  Remaining Estimate: 0h
>
> Phoenix's SCN feature has some problems, because HBase major compaction can 
> remove Cells that have been deleted or whose TTL or max versions has caused 
> them to be expired. 
> For example, IndexTool rebuilds and index scrutiny can both give strange, 
> incorrect results if a major compaction occurs in the middle of their run. In 
> the rebuild case, it's because we're rewriting "history" on the index at the 
> same time that compaction is rewriting "history" by purging deleted and 
> expired cells. 
> Create a new configuration property called "max lookback age", which declares 
> that no data written more recently than the max lookback age will be 
> compacted away. The max lookback age must be smaller than the TTL, and it 
> should not be legal for a user to look back further in the past than the 
> table's TTL. 
> Max lookback age by default will not be set, and the current behavior will be 
> preserved. But if max lookback age is set, it will be enforced by the 
> BaseScannerRegionObserver for all tables. 
> In the future, this should be contributed as a general feature to HBase for 
> arbitrary tables. See HBASE-23602.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to