[
https://issues.apache.org/jira/browse/HBASE-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216864#comment-15216864
]
stack commented on HBASE-14920:
-------------------------------
s/startCompact/startCompaction/g
s/doCompact/doCompaction/g
No need of these things...
445
/*----------------------------------------------------------------------
no one else does this...
Oh... so we could let go of an edit because it was beyond max versions or
something and then you need to update the lowest outstanding sequenceid ....
this thing?
465 updateLowestUnflushedSequenceIdInWal(true); // only if greater
I'd never have thought to do that.
We are changing the flush policy on the user here?
944 if(hasCompactingStore) {
945 double alpha = FLUSH_SIZE_WEIGHT;
946 this.memstoreFlushSize =
947 (long)(alpha*memstoreFlushSize +
(1-alpha)*blockingMemStoreSize);
948 LOG.info("Increasing memstore flush size to
"+memstoreFlushSize +" for the region="
949 + this);
950
htableDescriptor.setFlushPolicyClassName(FlushNonCompactingStoresFirstPolicy.class
951 .getName());
952 }
Thats not bad in-itself (just Release Note it as well as the fact that we are
going to run w/ more memory), but we are doing it by setting policy on the
HTableDescriptor; every region is going to do this? Can we do it on the region
itself? Or can we get away w/o changing HTD? This is unusual practice.
Do you have to start your own? Can you not piggyback off the RS's existing
Executor?
1748
this.service.startExecutorService(ExecutorType.RS_IN_MEMORY_FLUSH_AND_COMPACTION,
1749
conf.getInt("hbase.regionserver.executor.inmemoryflush.threads", 3));
Do you need to add this one to RegionServicesFor...
56 public HTableDescriptor getTableDesc() {
57 return region.getTableDesc();
58 }
Would be good if you could get away w/ not passing it down...
And this one...
68 public RegionServerServices getRegionServerServices() {
69 return region.getRegionServerServices();
70 }
This onlyIfGreater was there before you?
168 void updateStore(byte[] encodedRegionName, byte[] familyName, Long
sequenceId,
169 boolean onlyIfGreater) {
We should purge it? It is of little use?
TestCompactingMemStore is junit3 rather than junit4 because it parent is. I'll
attach a patch here that moves TestDefaultMemStore to junit4 so this test can
be junit 4 too (We've been trying to purge the old tests...)
I skimmed the tests. They look great.
Looks committable to me.
> Compacting Memstore
> -------------------
>
> Key: HBASE-14920
> URL: https://issues.apache.org/jira/browse/HBASE-14920
> Project: HBase
> Issue Type: Sub-task
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-14920-V01.patch, HBASE-14920-V02.patch
>
>
> Implementation of a new compacting memstore with non-optimized immutable
> segment representation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)