Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 34B80FA02 for ; Thu, 4 Apr 2013 01:02:15 +0000 (UTC) Received: (qmail 94979 invoked by uid 500); 4 Apr 2013 01:02:14 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 94937 invoked by uid 500); 4 Apr 2013 01:02:14 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 94927 invoked by uid 99); 4 Apr 2013 01:02:14 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Apr 2013 01:02:14 +0000 Date: Thu, 4 Apr 2013 01:02:14 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-4198) Harmonize HBA flush, compact and majorCompact MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4198: ------------------------- Fix Version/s: (was: 0.95.0) Moving unassigned improvement out of 0.95 > Harmonize HBA flush, compact and majorCompact > --------------------------------------------- > > Key: HBASE-4198 > URL: https://issues.apache.org/jira/browse/HBASE-4198 > Project: HBase > Issue Type: Improvement > Affects Versions: 0.90.4 > Reporter: Jean-Daniel Cryans > > As I mentioned on the mailing list, the way HBA.flush behaves is different from what is used to be. Right now here's how flush and compact work: > - When calling HBA.flush it will fetch the list of regions then will contact their owners directly one by one and the flush will be done inline. The major issue here is flushing a big table will take a *long* time, but it does give some guarantee that all the flushes are done. The old behavior was that all flushes were done async. > - For compactions it also calls every regions' owners one by one and instead of being inline the compactions are queued. This is not very different from the old behavior, except that the master has nothing to do now. > What I believe we need to do: > - Both methods should have the same guarantees, either they return when everything is flushed/compacted or they don't. > - If we do inlining, we should issue the requests in parallel a la HTable.batch. > - We definitely need to offer an async version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira