[
https://issues.apache.org/jira/browse/HBASE-23143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Cang updated HBASE-23143:
----------------------------
Description:
Region Server Crash due to 2 cells out of order ( between 2 DELETEs)
Caused by: java.io.IOException: Added a key not lexically larger than previous.
Current cell =
00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095189597*/DeleteColumn/vlen=0/seqid=*2128373*,
lastCell =
00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095165147*/DeleteColumn/vlen=0/seqid=*2128378*
I am aware of this JIRA: https://issues.apache.org/jira/browse/HBASE-22862
Though it's slightly different, HBASE-22862 issue was caused One Delete and One
Put.
This issue I am reporting is caused by 2 Deletes
Has anyone seen this issue?
After I read the code and debugged the test cases.
In AbstractHFileWriter.java
{code:java}
int keyComp = comparator.compareOnlyKeyPortion(lastCell, cell);{code}
This call will always ignore SequenceId. And time stamps are in the correct
order (above case)
And since these 2 cells have same KEY. The comparison result should be 0.
*only possible issue I can think of is, in this code piece: in
CellComparator.java:*
{code:java}
Bytes.compareTo(left.getRowArray(), left.getRowOffset(), left.getRowLength(),
right.getRowArray(), right.getRowOffset(), right.getRowLength());{code}
The getRowLength() returns a wrong value.
Or the offset is messed up. (?)
was:
Region Server Crash due to 2 cells out of order ( between 2 DELETEs)
Caused by: java.io.IOException: Added a key not lexically larger than previous.
Current cell =
00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095189597*/DeleteColumn/vlen=0/seqid=*2128373*,
lastCell =
00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095165147*/DeleteColumn/vlen=0/seqid=*2128378*
I am aware of this JIRA: https://issues.apache.org/jira/browse/HBASE-22862
Though it's slightly different, HBASE-22862 issue was caused One Delete and One
Put.
This issue I am reporting is caused by 2 Deletes
Has anyone seen this issue?
After I read the code and debugged the test cases.
In AbstractHFileWriter.java
{code:java}
int keyComp = comparator.compareOnlyKeyPortion(lastCell, cell);{code}
This call will always ignore SequenceId. And time stamps are in the correct
order (above case)
And since these 2 cells have same KEY. T*he comparison result should be 0.*
*only possible issue I can think of is, in this code piece: in
CellComparator.java:*
{code:java}
Bytes.compareTo(left.getRowArray(), left.getRowOffset(), left.getRowLength(),
right.getRowArray(), right.getRowOffset(), right.getRowLength());{code}
The getRowLength() returns a wrong value.
Or the offset is messed up. (?)
> Region Server Crash due to 2 cells out of order ( between 2 DELETEs)
> --------------------------------------------------------------------
>
> Key: HBASE-23143
> URL: https://issues.apache.org/jira/browse/HBASE-23143
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.3.2
> Reporter: Xu Cang
> Priority: Major
>
> Region Server Crash due to 2 cells out of order ( between 2 DELETEs)
>
> Caused by: java.io.IOException: Added a key not lexically larger than
> previous.
> Current cell =
> 00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095189597*/DeleteColumn/vlen=0/seqid=*2128373*,
>
> lastCell =
> 00D7F000000xxQ10D52v00008UY6yV0057F000000bPaGT\x000000000000000000057F000000bPaG/0:TABLE1_ID/*1570095165147*/DeleteColumn/vlen=0/seqid=*2128378*
>
>
> I am aware of this JIRA: https://issues.apache.org/jira/browse/HBASE-22862
> Though it's slightly different, HBASE-22862 issue was caused One Delete and
> One Put.
> This issue I am reporting is caused by 2 Deletes
>
> Has anyone seen this issue?
>
> After I read the code and debugged the test cases.
> In AbstractHFileWriter.java
> {code:java}
> int keyComp = comparator.compareOnlyKeyPortion(lastCell, cell);{code}
> This call will always ignore SequenceId. And time stamps are in the correct
> order (above case)
> And since these 2 cells have same KEY. The comparison result should be 0.
> *only possible issue I can think of is, in this code piece: in
> CellComparator.java:*
> {code:java}
> Bytes.compareTo(left.getRowArray(), left.getRowOffset(), left.getRowLength(),
> right.getRowArray(), right.getRowOffset(), right.getRowLength());{code}
> The getRowLength() returns a wrong value.
> Or the offset is messed up. (?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
