[ https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
chenglei updated PHOENIX-5307: ------------------------------ Description: I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262: {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 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. was: I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262, which is different from this JIRA: {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 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. > 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 > Attachments: PHOENIX-5307_v1-4.x-HBase-1.4.patch > > > I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262: > {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 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 (v7.6.3#76005)