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

stack commented on HBASE-17081:
-------------------------------

bq. ...and IMHO there is no reason to revert it.

[~ebortnik] Edward. FYI. Devs are perfectly within-their-rights reverting 
patches that introduce test failures. Failing tests hinder progress as devs 
need to track if their patch introduced the new failures. That this patch 
caused UT failures indirectly and that perhaps the dev could have done the 
revert in a less radical way is not for them to figure; the burden is upon the 
contributor whose patch is causing failing tests.

Sometimes it takes a few cycles of revert/commit to land an awkward patch. No 
harm done.

> Flush the entire CompactingMemStore content to disk
> ---------------------------------------------------
>
>                 Key: HBASE-17081
>                 URL: https://issues.apache.org/jira/browse/HBASE-17081
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anastasia Braginsky
>            Assignee: Anastasia Braginsky
>         Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, 
> HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, 
> HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, 
> HBASE-17081-V07.patch, HBaseMeetupDecember2016-V02.pptx, 
> Pipelinememstore_fortrunk_3.patch
>
>
> Part of CompactingMemStore's memory is held by an active segment, and another 
> part is divided between immutable segments in the compacting pipeline. Upon 
> flush-to-disk request we want to flush all of it to disk, in contrast to 
> flushing only tail of the compacting pipeline.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to