[
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!
Anastasia
> 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)
