[
https://issues.apache.org/jira/browse/HBASE-27332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaolin Ha updated HBASE-27332:
-------------------------------
Description:
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.
was:
As disscussed in
[https://github.com/apache/hbase/pull/4725|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.
> Remove RejectedExecutionHandler for long/short compaction thread pool
> ---------------------------------------------------------------------
>
> 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
> 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)
