[jira] Commented: (HBASE-855) compaction can return less versions then we should in some cases

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627234#action_12627234 ] 

stack commented on HBASE-855:
-----------------------------

Thanks Billy.  TestCompactions is failing since we changed how compactions are done.  I was looking at it yesterday and was thinking that 855 was not fully to blame.  This new bug in our max versions logic might explain it.  Let me test.

> compaction can return less versions then we should in some cases
> ----------------------------------------------------------------
>
>                 Key: HBASE-855
>                 URL: https://issues.apache.org/jira/browse/HBASE-855
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.2.1, 0.18.0
>            Reporter: Billy Pearson
>            Assignee: Billy Pearson
>             Fix For: 0.2.1, 0.18.0
>
>         Attachments: 855-patch.txt
>
>
> say we have a column with max version = 3 and we have 3 records  
> we insert a new record with a old timestamp.
> What happeds in the compaction is the the new record with the old timestamp get read first and could push out some of our 
> versions if the new record(s) with the old timestamp has a expired ttl.
> This happens because we track the total times we see a row/column but do not reduce this count if the cell is expired
> and sense we pass the cell in order of the newest HStoreFile first with the newest records passed might not be the newest timestamps.
> Got to wait for HBASE-834 to be committed then I can add a patch for this bug. will be a simple fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.