hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anastasia Braginsky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17081) Flush the entire CompactingMemStore content to disk
Date Mon, 19 Dec 2016 14:16:58 GMT

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

Anastasia Braginsky commented on HBASE-17081:

Good Day Amazing Team!

I think quite a big mess is going here and I didn’t say anything about it yet! How come?
No big problems, everything is under control, we will manage it all greatly! :)

So let insert some order here and redirect the discussions to the correct JIRAs as all recent
discussions are not related to this JIRA.
Here are the facts:
1. Making the default MemStore to be CompactingMemStore with the BASIC mode was *not* introduced
in this JIRA, but in HBASE-17294. At least, denying the commit of this JIRA won’t help you
to resolve the problem of BASIC CompactingMemStore being the default.

As a (big) side node, BASIC CompactingMemStore means flattening of the immutable segments
and flushing everything to disk upon snapshot request. No merges and no compactions are made
with BASIC CompactingMemStore. So it works similarly to DefaultMemStore just little better.
The decision about that was pronounced in HBASE-16851 and then implemented in HBASE-17294.
I agree with Anoop that it wasn’t pronounced loudly enough so may be some people missed
those two JIRAs. So let us return to those JIRAs and discuss it all there. At least, this
JIRA is not about that. Now continuing with the facts:

2. Let assume that the problem with TestAsyncGetMultiThread was introduced with this JIRA
and not with HBASE-17294 and not in any other commit. We don’t have clear evidences for
that, but let assume it is so. So after this JIRA’s commit was reverted everything should
be fine, isn’t it? We (with your help) are going to debug it and then resubmit the patch.
3. HBASE-17333 was opened in order to revert the changes done by HBASE-17294 and make the
DefaultMemStore default again. First, it can be done easily just by changing two lines in
the switch that Ram presented above. This will bring the situation to as it was prior to HBASE-17294.
If you want to change the configuration to work with some other property in hbase-site let
discuss is prior to your commit.

So bottom line, this patch is reverted, no tests fail, we are all good so far. Let continue
to discuss all the issues on the related JIRAs. 
And of course big thanks to all those involved in the current investigation. 

Happy Holidays!

> 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

View raw message