[
https://issues.apache.org/jira/browse/HBASE-23143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949159#comment-16949159
]
ramkrishna.s.vasudevan commented on HBASE-23143:
------------------------------------------------
Reading the Cells that you have and the code
{code}
if (lastCell != null) {
int keyComp = comparator.compareOnlyKeyPortion(lastCell, cell);
{code}
Here we pass lastCell as the 'left' and 'cell' as the right. Generally
timestamp is swapped.
{code}
@Override
public int compareTimestamps(final long ltimestamp, final long rtimestamp) {
// Swap order we pass into compare so we get DESCENDING order.
return Long.compare(rtimestamp, ltimestamp);
}
{code}
So here since the currentCell has the bigger TS we get this exception. But the
seqId of the cells as in the log is that the currentCell has lesser seqID than
the lastCell.
So I suspect how things were added to the memstore. First question is that -
how is the Timestamp added? Is it added by the client in this case?
> 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
> Fix For: 1.4.12, 1.3.7, 1.5.1
>
>
> 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)
