Return-Path: Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: (qmail 65879 invoked from network); 26 Jan 2011 04:35:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Jan 2011 04:35:02 -0000 Received: (qmail 68143 invoked by uid 500); 26 Jan 2011 04:35:02 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 67763 invoked by uid 500); 26 Jan 2011 04:34:59 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 67755 invoked by uid 99); 26 Jan 2011 04:34:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jan 2011 04:34:58 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mac.hadoop@gmail.com designates 209.85.161.169 as permitted sender) Received: from [209.85.161.169] (HELO mail-gx0-f169.google.com) (209.85.161.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jan 2011 04:34:50 +0000 Received: by gxk5 with SMTP id 5so2239516gxk.14 for ; Tue, 25 Jan 2011 20:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gVTxIkdJVsOE/EJf0HyZ0bYx+WQfw8H++KhFuq84HPA=; b=HGnFJe5NK+qoEHSWdvQDkArQ7KV+G/Lzxbx3Wdf0udFczFK7wmJ2+gIaEOnJextpQi QW7saxwTQT8z0tgMl0b3y29eIX51Y6ZqZ922GRnvfIy7koxPAK3wWVTFyi7bkKyTOdfP ecnGtxDGWs5YQt17kGfrJb80r64Zd0/JYoHqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OzPr/wNquNTmQ0k1Uk4IoWJSuM2+tA5z4wKVxOBUzYHfpxB3lxPC6va2woJudWr4a8 Z4OsV5LBUyoFqVJT+vVRI9tRujMdoHCB2gKQP6YFstkEsQYxfsCwlyNQR4IU43eMHGxB o0YqVeOVzDGNeYhVNctdO5qREysA6w+fFUh1k= MIME-Version: 1.0 Received: by 10.100.111.18 with SMTP id j18mr4504188anc.255.1296016468974; Tue, 25 Jan 2011 20:34:28 -0800 (PST) Received: by 10.146.167.10 with HTTP; Tue, 25 Jan 2011 20:34:28 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Jan 2011 12:34:28 +0800 Message-ID: Subject: Re: Looks like duplicate in MemoryStoreFlusher flushSomeRegions() From: mac fang To: dev@hbase.apache.org Content-Type: multipart/alternative; boundary=0016e642d15a419e8d049ab85964 X-Virus-Checked: Checked by ClamAV on apache.org --0016e642d15a419e8d049ab85964 Content-Type: text/plain; charset=ISO-8859-1 Oh, yes, I checked the code, the method protected CompactionRequest addToRegionsInQueue(HRegion r, int p) { contains the: if (queuedRequest == null || newRequest.getPriority() < queuedRequest.getPriority()) { LOG.trace("Inserting region in queue. " + newRequest); regionsInQueue.put(r, newRequest); So it should be OK. Thanks for remind. regards macf On Wed, Jan 26, 2011 at 10:30 AM, Ryan Rawson wrote: > it does seem like the call to compactionRequested calls in > > (Class MemStoreFlusher) > private synchronized void flushSomeRegions(); > > are superfluous. Due to the nature of the compaction algorithm this > should not cause extra compaction, so the impact should be minimal, > but ideally should be removed. > > -ryan > > On Tue, Jan 25, 2011 at 6:23 PM, Ryan Rawson wrote: > > the call to compactionRequested() only puts the region on a queue to > > be compacted, so if there is unintended duplication, it wont actually > > hold anything up. > > > > -ryan > > > > On Tue, Jan 25, 2011 at 6:05 PM, mac fang wrote: > >> Guys, since the flushCache will make the write/read suspend. I am NOT > sure > >> if it is necessary here. > >> > >> On Mon, Jan 24, 2011 at 1:48 PM, mac fang wrote: > >> > >>> Yes, I mean the server.compactSplitThread.compactionRequested(region, > >>> getName()); > >>> > >>> in flushRegion, it will do the > server.compactSplitThread.compactionRequested(region, > >>> getName()); > >>> > >>> *seems we don't need to do it again in the following logic (can you > guys > >>> see the lines in bold, **!flushRegion(biggestMemStoreRegion, true) and > * > >>> * > >>> * > >>> * for (HRegion region : regionsToCompact) { > >>> server.compactSplitThread.compactionRequested(region, getName()); > >>> }* > >>> * > >>> * > >>> * > >>> * > >>> *regards* > >>> macf > >>> > >>> > >>> if (*!flushRegion(biggestMemStoreRegion, true)*) { > >>> LOG.warn("Flush failed"); > >>> break; > >>> } > >>> regionsToCompact.add(biggestMemStoreRegion); > >>> } > >>> for (HRegion region : regionsToCompact) { > >>> *server.compactSplitThread.compactionRequested(region, > getName());* > >>> } > >>> > >>> > > in flushRegion > >>> > > > >>> > > private boolean flushRegion(final HRegion region, final boolean > >>> > > emergencyFlush) { > >>> > > synchronized (this.regionsInQueue) { > >>> > > FlushQueueEntry fqe = this.regionsInQueue.remove(region); > >>> > > if (fqe != null && emergencyFlush) { > >>> > > // Need to remove from region from delay queue. When NOT an > >>> > > // emergencyFlush, then item was removed via a > flushQueue.poll. > >>> > > flushQueue.remove(fqe); > >>> > > } > >>> > > lock.lock(); > >>> > > } > >>> > > try { > >>> > > if (region.flushcache()) { > >>> > > *server.compactSplitThread.compactionRequested(region, > >>> getName());* > >>> > > } > >>> > >>> On Mon, Jan 24, 2011 at 6:40 AM, Ted Yu wrote: > >>> > >>>> I think he was referring to this line: > >>>> > >>>> server.compactSplitThread.compactionRequested(region, getName()); > >>>> > >>>> On Sun, Jan 23, 2011 at 10:52 AM, Stack wrote: > >>>> > >>>> > Hello Mac Fang: Which lines in the below? Your colorizing didn't > >>>> > come across in the mail. Thanks, St.Ack > >>>> > > >>>> > On Sun, Jan 23, 2011 at 6:23 AM, mac fang > wrote: > >>>> > > Hi, guys, > >>>> > > > >>>> > > see the below codes in* MemStoreFlusher.java*, i am not sure if > those > >>>> > lines > >>>> > > in orange are the same and looks like they are trying to do the > same > >>>> > logic. > >>>> > > Are they redundant? > >>>> > > > >>>> > > regards > >>>> > > macf > >>>> > > > >>>> > > if (!flushRegion(biggestMemStoreRegion, true)) { > >>>> > > LOG.warn("Flush failed"); > >>>> > > break; > >>>> > > } > >>>> > > regionsToCompact.add(biggestMemStoreRegion); > >>>> > > } > >>>> > > for (HRegion region : regionsToCompact) { > >>>> > > server.compactSplitThread.compactionRequested(region, > getName()); > >>>> > > } > >>>> > > > >>>> > > in flushRegion > >>>> > > > >>>> > > private boolean flushRegion(final HRegion region, final boolean > >>>> > > emergencyFlush) { > >>>> > > synchronized (this.regionsInQueue) { > >>>> > > FlushQueueEntry fqe = this.regionsInQueue.remove(region); > >>>> > > if (fqe != null && emergencyFlush) { > >>>> > > // Need to remove from region from delay queue. When NOT > an > >>>> > > // emergencyFlush, then item was removed via a > flushQueue.poll. > >>>> > > flushQueue.remove(fqe); > >>>> > > } > >>>> > > lock.lock(); > >>>> > > } > >>>> > > try { > >>>> > > if (region.flushcache()) { > >>>> > > server.compactSplitThread.compactionRequested(region, > >>>> getName()); > >>>> > > } > >>>> > > > >>>> > > >>>> > >>> > >>> > >> > > > --0016e642d15a419e8d049ab85964--