You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Chinmay Kulkarni (Jira)" <ji...@apache.org> on 2019/12/21 00:56:08 UTC
[jira] [Closed] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961
failing after PHOENIX-5262
[ https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chinmay Kulkarni closed PHOENIX-5307.
-------------------------------------
Bulk closing Jiras for the 4.15.0 release.
> Fix HashJoinMoreIT.testBug2961 failing after PHOENIX-5262
> ---------------------------------------------------------
>
> Key: PHOENIX-5307
> URL: https://issues.apache.org/jira/browse/PHOENIX-5307
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0
> Reporter: chenglei
> Assignee: chenglei
> Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5307_v1-4.x-HBase-1.4.patch
>
>
> I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262, and the error stack is different from PHOENIX-5290:
> {code}
> java.lang.AssertionError
> at org.apache.phoenix.end2end.join.HashJoinMoreIT.testBug2961(HashJoinMoreIT.java:908)
> {code}
> I think this problem is caused by following line 453 modified in PHOENIX-5262:
> {code}
> 445 if ( !isFixedWidth && ( sepByte == QueryConstants.DESC_SEPARATOR_BYTE
> 446 || ( !exclusiveUpper
> 447 && (fieldIndex < schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448 key[offset++] = sepByte;
> 449 // Set lastInclusiveUpperSingleKey back to false if this is the last pk column
> 450 // as we don't want to increment the null byte in this case
> 451 // To test if this is the last pk column we need to consider the span of this slot
> 452 // and the field index to see if this slot considers the last column
> 453 lastInclusiveUpperSingleKey &= (fieldIndex + slotSpan[i]) < schema.getMaxFields()-1;
> 454 }
> {code}
> It did not consider the case that the last field is variable length and also DESC, when the last field is variable length and also {{DESC}}, the trailiing {{0xFF}} is not removed when stored in HBASE, so for such case, we should not set {{lastInclusiveUpperSingleKey}} back to false.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)