[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[
https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated PHOENIX-5307:
--
Attachment: PHOENIX-5307_v1-4.x-HBase-1.4.patch
> Fix HashJoinMoreIT.testBug2961 failed 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,
> 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}
> 445if ( !isFixedWidth && ( sepByte ==
> QueryConstants.DESC_SEPARATOR_BYTE
> 446|| ( !exclusiveUpper
> 447 && (fieldIndex <
> schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448key[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
> 453lastInclusiveUpperSingleKey &= (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, so for such case, we should not set
> {{lastInclusiveUpperSingleKey}} back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[
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,
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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (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, 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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (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, so for such field, we should not set
{{lastInclusiveUpperSingleKey}} back to false.
> Fix HashJoinMoreIT.testBug2961 failed 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
>Priority: Major
>
> 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}
> 445if ( !isFixedWidth && ( sepByte ==
> QueryConstants.DESC_SEPARATOR_BYTE
> 446|| ( !exclusiveUpper
> 447 && (fieldIndex <
> schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448key[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
> 453lastInclusiveUpperSingleKey &= (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, so for such case, we should not set
> {{lastInclusiveUpperSingleKey}} back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[
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,
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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (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, so for such field, 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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (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, so
for such field, we should not set lastInclusiveUpperSingleKey back to false.
> Fix HashJoinMoreIT.testBug2961 failed 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
>Priority: Major
>
> 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}
> 445if ( !isFixedWidth && ( sepByte ==
> QueryConstants.DESC_SEPARATOR_BYTE
> 446|| ( !exclusiveUpper
> 447 && (fieldIndex <
> schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448key[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
> 453lastInclusiveUpperSingleKey &= (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, so for such field, we should not set
> {{lastInclusiveUpperSingleKey}} back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[
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,
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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (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, so
for such field, 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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (fieldIndex + slotSpan[i]) <
schema.getMaxFields()-1;
454 }
{code}
It did not consider the case that last field is variable length and is DESC,
when the last field is variable length and is DESC, the trailiing 0xFF is not
removed, so
for such field, we should not set lastInclusiveUpperSingleKey back to false.
> Fix HashJoinMoreIT.testBug2961 failed 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
>Priority: Major
>
> 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}
> 445if ( !isFixedWidth && ( sepByte ==
> QueryConstants.DESC_SEPARATOR_BYTE
> 446|| ( !exclusiveUpper
> 447 && (fieldIndex <
> schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448key[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
> 453lastInclusiveUpperSingleKey &= (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, so
> for such field, we should not set lastInclusiveUpperSingleKey back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[
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,
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}
445if ( !isFixedWidth && ( sepByte ==
QueryConstants.DESC_SEPARATOR_BYTE
446|| ( !exclusiveUpper
447 && (fieldIndex <
schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
448key[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
453lastInclusiveUpperSingleKey &= (fieldIndex + slotSpan[i]) <
schema.getMaxFields()-1;
454 }
{code}
It did not consider the case that last field is variable length and is DESC,
when the last field is variable length and is DESC, the trailiing 0xFF is not
removed, so
for such field, we should not set lastInclusiveUpperSingleKey back to false.
> Fix HashJoinMoreIT.testBug2961 failed 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
>Priority: Major
>
> 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}
> 445if ( !isFixedWidth && ( sepByte ==
> QueryConstants.DESC_SEPARATOR_BYTE
> 446|| ( !exclusiveUpper
> 447 && (fieldIndex <
> schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448key[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
> 453lastInclusiveUpperSingleKey &= (fieldIndex + slotSpan[i])
> < schema.getMaxFields()-1;
> 454 }
> {code}
> It did not consider the case that last field is variable length and is DESC,
> when the last field is variable length and is DESC, the trailiing 0xFF is not
> removed, so
> for such field, we should not set lastInclusiveUpperSingleKey back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
[ https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenglei updated PHOENIX-5307: -- Summary: Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262 (was: Fix HashJoinMoreIT.test failed after PHOENIX-5262) > Fix HashJoinMoreIT.testBug2961 failed 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 >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
