Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 70AD3ECAB for ; Sun, 30 Dec 2012 16:26:17 +0000 (UTC) Received: (qmail 75325 invoked by uid 500); 30 Dec 2012 16:26:15 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 75276 invoked by uid 500); 30 Dec 2012 16:26:15 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 75265 invoked by uid 99); 30 Dec 2012 16:26:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Dec 2012 16:26:15 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.219.48] (HELO mail-oa0-f48.google.com) (209.85.219.48) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Dec 2012 16:26:04 +0000 Received: by mail-oa0-f48.google.com with SMTP id h2so11135022oag.35 for ; Sun, 30 Dec 2012 08:25:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=VW/cnt4FaKLb8TaNUwQHIWABmr4AGaeWM5AQmy+W/Ao=; b=fx+I7rcc+InJICVPIWN+2Hi0elNBijJR1edTjcT9KaP8x+vj3L44CFfBz2ze7W4w2Q cXe7B0LQvAqGE3GDY1Emb8BkanGQZgIL/w23VhKTV97JQGnzNdDxNislMXvMpEf1L9w4 V7hGYF7kx56JXN2T6JJ+GGrz2EL3Xd+XIAhUQLNk0RJYhEP+aE1XeZFK/IB34JHQvfwM WgJ+0NwIlElLIK5gBX78YM9LkJCoDSSjWFUe67GdqJ5jwmo2gXa2IMTwuAJHemBEbg9w /jhC4Oi3iK5qcV0oszZ1CGAhcECPp+E5bT5+Nfdjz//AdUQfXhBtfUpOzF3zF27Wjr5O wGxw== MIME-Version: 1.0 Received: by 10.60.172.6 with SMTP id ay6mr20136906oec.10.1356884743585; Sun, 30 Dec 2012 08:25:43 -0800 (PST) Received: by 10.182.153.36 with HTTP; Sun, 30 Dec 2012 08:25:43 -0800 (PST) Date: Sun, 30 Dec 2012 11:25:43 -0500 Message-ID: Subject: Best way to compact a region after a move? From: Jean-Marc Spaggiari To: user Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlVZ5YoC6clRhGNt/Rn5IKTdi/dH2Ubd67iqHfvfuObgsWcsAqBySLbXfzfWiWQsRPG4hKr X-Virus-Checked: Checked by ClamAV on apache.org Hi, When I'm balancing manually the regions on my cluster, and I want to make sure they are local, so I want to major_compact them each time I'm moving them. On the balanceCluster method, we are returning a list of region to move. Which mean they are not yet moved, so I can't compact them there. Is there a place where I shoud hook to compact those regions? So far, the only idea I found was to start a thread on the balancerCluster, wait 1 minute, and compact all the regions I returned. But I'm wondering if there is a better way to achieve that? Is there a queue where I should place those regions to compact instead? Also, I need to know (even if it's just in the logs) when those compactions are done. Thanks, JM