Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@hbase.apache.org)
MIME-Version: 1.0
In-Reply-To: 
 <CALte62yUG1h2CLfGfydvgYT2keJmnkZzNafYNb13SUPLDfSijA@mail.gmail.com>
References: <201504212110335571577@sina.com>
	<CAAAYAnOOODYGPgR9-Jtx_SOOeeHA5RFAnqx9UXPDf_jvY7CFnA@mail.gmail.com>
	<CALte62yUG1h2CLfGfydvgYT2keJmnkZzNafYNb13SUPLDfSijA@mail.gmail.com>
Date: Wed, 22 Apr 2015 07:12:10 +0800
Message-ID: 
 <CAAAYAnNC06E-pUG_Fhu9-7x5z--tm_apnFqpuqfn=LdNESE3mA@mail.gmail.com>
Subject: Re: A compact bug?
From: =?UTF-8?B?5byg6ZOO?= <palomino219@gmail.com>
To: Ted Yu <yuzhihong@gmail.com>
Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>, sershe <sershe@apache.org>
Content-Type: multipart/alternative; boundary=001a114904682022090514442d37

--001a114904682022090514442d37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

These code is wrapped by a 'if (this.compaction =3D=3D null)', so the code =
will
only be executed when selectNow =3D=3D false.

2015-04-21 22:49 GMT+08:00 Ted Yu <yuzhihong@gmail.com>:

> In CompactionRunner#run(), we have:
>
>         // Now see if we are in correct pool for the size; if not, go to
> the correct one.
>
>         // We might end up waiting for a while, so cancel the selection.
>
>         assert this.compaction.hasSelection();
>
>         ThreadPoolExecutor pool =3D store.throttleCompaction(
>
>             compaction.getRequest().getSize()) ? longCompactions :
> shortCompactions;
>
>         if (this.parent !=3D pool) {
>
>           this.store.cancelRequestedCompaction(this.compaction);
>
> The above code would adjust to the correct pool, right ?
>
>
> Cheers
>
> On Tue, Apr 21, 2015 at 7:10 AM, =E5=BC=A0=E9=93=8E <palomino219@gmail.co=
m> wrote:
>
>> I think it is a bug. According to the comment above, they just want to
>> put system compactions(selectNow =3D=3D false) to the small pool, so the=
 code
>> should like this
>>
>> ThreadPoolExecutor pool;
>> if (selectNow) {
>>   pool =3D s.throttleCompaction(compaction.getRequest().getSize())
>> ? longCompactions : shortCompactions;
>> } else {
>>   pool =3D shortCompactions;
>> }
>>
>> My code is on master so ignore the variable name differences...
>>
>> Would you mind open a issue on jira?
>>
>> Thanks.
>>
>> 2015-04-21 21:10 GMT+08:00 zhou_shuaifeng@sina.com <
>> zhou_shuaifeng@sina.com>:
>>
>>> Hi all,
>>>
>>> In compactsplitthread.java, the requestCompactionInternal method is lik=
e
>>> this:
>>>
>>>   private synchronized CompactionRequest requestCompactionInternal(fina=
l
>>> HRegion r, final Store s,
>>> ...
>>>
>>>     ThreadPoolExecutor pool =3D (!selectNow && s.throttleCompaction(siz=
e))
>>>       ? largeCompactions : smallCompactions;
>>>
>>> ...
>>>
>>> this will cause all compactions with selectNow =3Dtrue go to the small
>>> compaction queue, even the size is large enough, is it reasonable?
>>>
>>> I checked the commit history, this comes from HBASE-8665, is there any
>>> reason or a bug?
>>>
>>> thanks.
>>>
>>>
>>> zhou_shuaifeng@sina.com
>>>
>>
>>
>

--001a114904682022090514442d37--