[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Attachment: PHOENIX-4742_v1.patch > 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 > > Attachments: PHOENIX-4742_v1.patch > > > 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Attachment: (was: PHOENIX-4742_v1.patch) > 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 > > Attachments: PHOENIX-4742_v1.patch > > > 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Attachment: (was: PHOENIX-4742_v1.patch) > 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 > > Attachments: PHOENIX-4742_v1.patch > > > 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Attachment: PHOENIX-4742_v1.patch > 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 > > Attachments: PHOENIX-4742_v1.patch > > > 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Attachment: PHOENIX-4742_v1.patch > 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 > > Attachments: PHOENIX-4742_v1.patch > > > 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ 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)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Summary: DistinctPrefixFilter potentially seeks to lesser key when descending or null value (was: Prevent infinite loop with HBase 1.4 and DistinctPrefixFilter) > 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: Sergey Soldatov >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > 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). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4742) DistinctPrefixFilter potentially seeks to lesser key when descending or null value
[ https://issues.apache.org/jira/browse/PHOENIX-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4742: -- Fix Version/s: 5.0.0 4.14.0 > 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: Sergey Soldatov >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > 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). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
