Return-Path: <issues-return-271317-archive-asf-public=cust-asf.ponee.io@hbase.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id B2B5A200BF3
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Wed, 30 Nov 2016 12:12:00 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id B17EC160B08; Wed, 30 Nov 2016 11:12:00 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 056A5160B19
	for <archive-asf-public@cust-asf.ponee.io>; Wed, 30 Nov 2016 12:11:59 +0100 (CET)
Received: (qmail 44234 invoked by uid 500); 30 Nov 2016 11:11:58 -0000
Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@hbase.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@hbase.apache.org>
List-Post: <mailto:issues@hbase.apache.org>
List-Id: <issues.hbase.apache.org>
Delivered-To: mailing list issues@hbase.apache.org
Received: (qmail 43974 invoked by uid 99); 30 Nov 2016 11:11:58 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Nov 2016 11:11:58 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 90D0F2C2AB6
	for <issues@hbase.apache.org>; Wed, 30 Nov 2016 11:11:58 +0000 (UTC)
Date: Wed, 30 Nov 2016 11:11:58 +0000 (UTC)
From: "Anastasia Braginsky (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13020296.1478977301000.399934.1480504318590@Atlassian.JIRA>
In-Reply-To: <JIRA.13020296.1478977301000@Atlassian.JIRA>
References: <JIRA.13020296.1478977301000@Atlassian.JIRA> <JIRA.13020296.1478977301735@arcas>
Subject: [jira] [Commented] (HBASE-17081) Flush the entire
 CompactingMemStore content to disk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Wed, 30 Nov 2016 11:12:00 -0000


    [ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708264#comment-15708264 ] 

Anastasia Braginsky commented on HBASE-17081:
---------------------------------------------

Thank you [~stack] for your review! Hereby are my answers.

bq. 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.

So each scanner in the list of scanners should have an order number according to which one has the newer data. For example, the active segment has the highest order (biggest number) because its data is the freshest one. Then pipeline segments have the decreasing order from head to tail. If snapshot is represented as a single segment its order is 0. If this is a composite snapshot, then again the decreasing order from head to tail. The order shouldn't get to negative as it is initialized exactly according to the amount of segments in the memstore. However, I am adding a check for that to me on the safe side. This is not something new, we had this loop with decreasing order when dealing with pipeline segments before this patch.

bq. 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).

Fixed. In multiple places.

bq. Why KeyValueScanner instead of SegmentScanner? CellScanner?

Just to make MemStoreScanner and SegmentScanner to be from the same type as we are now interchange between them. I have now taken a look on CellScanner interface and it is much more lean interface than KeyValueScanner.

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