[
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15707725#comment-15707725
]
stack commented on HBASE-17081:
-------------------------------
Looking at patch:
215 public List<KeyValueScanner> getScanners(long readPoint, long order) {
216 List<KeyValueScanner> scanners = new
ArrayList<KeyValueScanner>(this.pipeline.size());
217 for (Segment segment : this.pipeline) {
218 scanners.add(segment.getScanner(readPoint, order));
219 order--;
220 }
221 return scanners;
222 }
How does order work in the above? Should we stop if it goes negative? Can it go
negative? We do the above pattern in another place at least in the patch.
Change
70 public List<Segment> getAllSegments() {
71 List<Segment> res = new LinkedList<Segment>(segments);
72 return res;
73 }
to return new LinkedList<Segment>(segments); No need to park in the local res
variable (This is done in a few places in the patch).
Why KeyValueScanner instead of SegmentScanner? CellScanner?
If we pass true for empty in below though all is zero, is it not-empty?
40 public MemstoreSize(boolean isEmpty) {
41 dataSize = 0;
42 heapOverhead = 0;
43 this.isEmpty = isEmpty;
44 }
Should emptyness be derivative of dataSize?
In other contstructor, what if the passed in dataSize is empty, is the size not
empty?
this.dataSize = dataSize;
Remove these rather than comment them out:
213 // assertTrue("\n<<< The memstore scanners with one snapshot are:
\n" + memstorescanners
214 // + "\n",false);
215
Otherwise, patch looks good to me. What you fellows thing, [~ram_krish] and
[~anoop.hbase]?
> 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, HBASE-17081-V04.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)
