[jira] [Commented] (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:comment-tabpanel=16487918#comment-16487918 ] Hudson commented on PHOENIX-4742: - FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #1885 (See [https://builds.apache.org/job/PreCommit-PHOENIX-Build/1885/]) PHOENIX-4742 DistinctPrefixFilter potentially seeks to lesser key when (jtaylor: rev 48b6f99acdeb91e3167e7beeed49747f7b7dcc6c) * (edit) phoenix-core/src/main/java/org/apache/phoenix/coprocessor/GroupedAggregateRegionObserver.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/DistinctPrefixFilter.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/SkipScanFilter.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/OrderByIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/RowKeySchema.java > 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] [Commented] (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:comment-tabpanel=16481479#comment-16481479 ] Hudson commented on PHOENIX-4742: - ABORTED: Integrated in Jenkins build Phoenix-4.x-HBase-1.3 #139 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.3/139/]) PHOENIX-4742 DistinctPrefixFilter potentially seeks to lesser key when (jtaylor: rev d7533f70212ec9cdb664b8f7d6d3814e3ec6e7f5) * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/OrderByIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/RowKeySchema.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/coprocessor/GroupedAggregateRegionObserver.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/DistinctPrefixFilter.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/SkipScanFilter.java > 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] [Commented] (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:comment-tabpanel=16481432#comment-16481432 ] Hudson commented on PHOENIX-4742: - SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-0.98 #1898 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-0.98/1898/]) PHOENIX-4742 DistinctPrefixFilter potentially seeks to lesser key when (jtaylor: rev 7cd3d561317832c979a4f7249c965ea66c603bc7) * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/SkipScanFilter.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/filter/DistinctPrefixFilter.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/OrderByIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/coprocessor/GroupedAggregateRegionObserver.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/RowKeySchema.java > 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] [Commented] (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:comment-tabpanel=16481356#comment-16481356 ] Mujtaba Chohan commented on PHOENIX-4742: - +1. LGTM. > 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] [Commented] (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:comment-tabpanel=16480170#comment-16480170 ] James Taylor commented on PHOENIX-4742: --- Anyone got time for a code review: [~sergey.soldatov], [~rajeshbabu], [~tdsilva]? > 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)
