[
https://issues.apache.org/jira/browse/HBASE-27332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17596994#comment-17596994
]
Xiaolin Ha commented on HBASE-27332:
------------------------------------
Thanks, [~bbeaudreault], OOME is bad failure mode, but the problem here is
that NO compaction runner will be rejected, because the PriorityBlockingQueue
is near unbounded in Java.
The compaction queue now is a PriorityBlockingQueue, which can not be bounded
by the default implementation. If we bound it, I think it is difficult to keep
the priority feature of the queue. If only size bound without priority, there
might store compactions be starved. Since the compaction queue length is
relevant to the store size on one regionserver, if it grows too large, I think
there must be some repeatly compaction requests for some stores, like the
scenes described in HBASE-26249, and we should avoid this using methods as in
that issue.
> Remove RejectedExecutionHandler for long/short compaction thread pools
> ----------------------------------------------------------------------
>
> Key: HBASE-27332
> URL: https://issues.apache.org/jira/browse/HBASE-27332
> Project: HBase
> Issue Type: Improvement
> Components: Compaction
> Affects Versions: 3.0.0-alpha-3, 2.4.13
> Reporter: Xiaolin Ha
> Assignee: Xiaolin Ha
> Priority: Minor
> Fix For: 2.6.0, 3.0.0-alpha-4
>
>
> As disscussed in https://github.com/apache/hbase/pull/4725
> actually the max size of StealJobQueue is bouded by the VM limit of an array,
> and the OOM exception occurs before the rejection handler. So StealJobQueue
> is equivalent to be unbounded. I think the RejectionHandler may bring some
> confusions and make the codes a little puzzle.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
