[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701883#comment-15701883 ]
Anastasia Braginsky commented on HBASE-17081: --------------------------------------------- Hi [~anoop.hbase], Thanks for your review and comments! I understand your concern that CompositeImmutableSegment is not truly some new type of Segment, but actually a wrap around a list of ImmutableSegments. However, this way we can (in majority of cases) encapsulate the composition of segments inside the snapshot. The CompactingMemStore (or any MemStore) should not be aware how exactly snapshot is implemented. I know this is not always true, and this is due to getCellSet(), because to create a single CellSet out of N segments will be too costly. But it would be wrong, to not to encapsulate at all just because we cannot encapsulate it always. So what you suggest is just to define snapshot as a List<ImmutableSegment> in the CompactingMemStore and then to deal with this list in the memstore code? We believe it would be a bad engineering practice. Or do I understand you wrongly? > 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-17081-V01.patch, HBASE-17081-V02.patch, > HBASE-17081-V03.patch, 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)