phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chenglei (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failing after PHOENIX-5262
Date Sat, 01 Jun 2019 02:24:00 GMT

     [ 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, 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.

  was:
 I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262, which 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.


> 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, 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
(v7.6.3#76005)

Mime
View raw message