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
>>
>
>
