[
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15760223#comment-15760223
]
ramkrishna.s.vasudevan commented on HBASE-17081:
------------------------------------------------
The problem was due to HBASE-17294.
{code}
String className = conf.get(MEMSTORE_CLASS_NAME,
DefaultMemStore.class.getName());
HColumnDescriptor.MemoryCompaction inMemoryCompaction =
family.getInMemoryCompaction();
if(inMemoryCompaction == null) {
inMemoryCompaction = HColumnDescriptor.MemoryCompaction.valueOf(conf.get
(CompactingMemStore.COMPACTING_MEMSTORE_TYPE_KEY,
CompactingMemStore.COMPACTING_MEMSTORE_TYPE_DEFAULT));
}
switch (inMemoryCompaction) {
case BASIC :
case EAGER :
className = CompactingMemStore.class.getName();
this.memstore = new CompactingMemStore(conf, this.comparator, this,
this.getHRegion().getRegionServicesForStores(), inMemoryCompaction);
break;
case NONE :
default:
this.memstore = ReflectionUtils.instantiateWithCustomCtor(className,
new Class[] {
Configuration.class, CellComparator.class }, new Object[] { conf,
this.comparator });
}
LOG.info("Memstore class name is " + className);
{code}
Why is that we are running with Compacting Memstore always? Even if the family
is not configured for in memory compaction. It has to be changed. This came as
part of HBASE-17294.
But one good thing is that it exposes some issues with Async client, which we
need to dig in.
> 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)
