[
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762151#comment-15762151
]
Edward Bortnikov commented on HBASE-17081:
------------------------------------------
All -
Thanks for chiming in. Apologies for possible misunderstanding - distributed
dev processes charge their toll :) . We are starting to suffer from the fact
that the Compacting Memstore project split into many small jira's, and it's
hard to track the full picture.
No problem at all with reverting specific patches if potential destabilization
suspected. My concern was scrapping or delaying the whole project without a
good reason, hence the suggestion to improve the discussion process and manage
it in a well-defined space.
Might be that the instability follows from the reverse order in which this Jira
and HBASE-17294 were checked in. The latter was supposed to be the concluding
chord, finalizing the configuration syntax and setting the new default.
Although we cannot reproduce the failures in problematic tests locally, how
about the following plan:
1. Revert both HBASE-17081 and HBASE-17294, and see if the regression is
stable.
2. Rebase and checkin HBASE-17081.
3. Rebase and checkin HBASE-17294.
4. Move the external documentation to HBASE-14918 (top-level JIRA), to improve
the visibility of the new definitions.
Thanks, again, for all the assistance identifying the problems so far.
> 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)
