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

Reply via email to