[
https://issues.apache.org/jira/browse/HBASE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-6908.
----------------------------------
Fix Version/s: 2.4.6
3.0.0-alpha-2
2.5.0
Hadoop Flags: Reviewed
Release Note:
Can pass in a FQCN to load as the call queue implementation.
Standardized arguments to the constructor are the max queue length, the
PriorityFunction, and the Configuration.
PluggableBlockingQueue abstract class provided to help guide the correct
constructor signature.
Hard fails with PluggableRpcQueueNotFound if the class fails to load as a
BlockingQueue<CallRunner>
Upstreaming on behalf of Hubspot, we are interested in defining our own custom
RPC queue and don't want to get involved in necessarily upstreaming internal
requirements/iterations.
Resolution: Fixed
Merged to branch-2.4+. Thanks for the clean pluggable Interface [~rmarsch] ....
I put your PR comment as release note. Edit if you see fit.
> Pluggable Call BlockingQueue for HBaseServer
> --------------------------------------------
>
> Key: HBASE-6908
> URL: https://issues.apache.org/jira/browse/HBASE-6908
> Project: HBase
> Issue Type: New Feature
> Components: IPC/RPC
> Reporter: James Taylor
> Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6
>
>
> Allow the BlockingQueue implementation class to be specified in the HBase
> config to enable different behavior than a FIFO queue. The use case we have
> is around fairness and starvation for big scans that are parallelized on the
> client. It's easy to fill up the HBase server Call BlockingQueue when
> processing a single parallelized scan, leadng other scans to time out.
> Instead, doing round robin processesing on a dequeue through a different
> BlockingQueue implementation will prevent this from occurring.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
