These code is wrapped by a 'if (this.compaction == null)', so the code will
only be executed when selectNow == false.
2015-04-21 22:49 GMT+08:00 Ted Yu <yuzhih...@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 = store.throttleCompaction(
>
> compaction.getRequest().getSize()) ? longCompactions :
> shortCompactions;
>
> if (this.parent != 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, 张铎 <palomino...@gmail.com> wrote:
>
>> I think it is a bug. According to the comment above, they just want to
>> put system compactions(selectNow == false) to the small pool, so the code
>> should like this
>>
>> ThreadPoolExecutor pool;
>> if (selectNow) {
>> pool = s.throttleCompaction(compaction.getRequest().getSize())
>> ? longCompactions : shortCompactions;
>> } else {
>> pool = 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_shuaif...@sina.com <
>> zhou_shuaif...@sina.com>:
>>
>>> Hi all,
>>>
>>> In compactsplitthread.java, the requestCompactionInternal method is like
>>> this:
>>>
>>> private synchronized CompactionRequest requestCompactionInternal(final
>>> HRegion r, final Store s,
>>> ...
>>>
>>> ThreadPoolExecutor pool = (!selectNow && s.throttleCompaction(size))
>>> ? largeCompactions : smallCompactions;
>>>
>>> ...
>>>
>>> this will cause all compactions with selectNow =true 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_shuaif...@sina.com
>>>
>>
>>
>
