[ 
https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-4742:
----------------------------------
    Description: 
DistinctPrefixFilter seeks to a smaller key than the current key (which causes 
an infinite loop in HBase 1.4 and seeks to every row in other HBase versions). 
This happens when:
 # Last column of distinct is descending. We currently always add a 0x01 byte, 
but since the separator byte if 0xFF when descending, the seek key is too small.
 # Last column value is null. In this case, instead of adding a 0x01 byte, we 
need to increment in-place the null value of the last distinct column. 

This was discovered due to 
OrderByIT.testOrderByReverseOptimizationWithNUllsLastBug3491 hanging in master.

  was:OrderByIT.testOrderByReverseOptimizationWithNUllsLastBug3491 is the only 
test failing on master (i.e. HBase 1.4). It's getting into an infinite loop 
when a reverse scan is done for the DistinctPrefixFilter. It'd be nice to fix 
this so we can do a release for HBase 1.4. At a minimum, we could disable 
DistinctPrefixFilter when a reverse scan is being done (for HBase 1.4 only).


> DistinctPrefixFilter potentially seeks to lesser key when descending or null 
> value
> ----------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4742
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4742
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>            Priority: Major
>             Fix For: 4.14.0, 5.0.0
>
>
> DistinctPrefixFilter seeks to a smaller key than the current key (which 
> causes an infinite loop in HBase 1.4 and seeks to every row in other HBase 
> versions). This happens when:
>  # Last column of distinct is descending. We currently always add a 0x01 
> byte, but since the separator byte if 0xFF when descending, the seek key is 
> too small.
>  # Last column value is null. In this case, instead of adding a 0x01 byte, we 
> need to increment in-place the null value of the last distinct column. 
> This was discovered due to 
> OrderByIT.testOrderByReverseOptimizationWithNUllsLastBug3491 hanging in 
> master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to