[
https://issues.apache.org/jira/browse/HBASE-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14391331#comment-14391331
]
Josh Elser commented on HBASE-13375:
------------------------------------
One more specific point that was noted was that, without preemption built in,
there isn't a way to ensure a strong bound on the number of RPC handlers in
use. Providing an unbounded number of handlers might be sufficient if it can be
adequately restricted (to prevent some denial of service attack -- malicious
or unintentional).
With a good preemption strategy, we can still ensure a nice upper bound on
resources and availability, but, until we get there, we'd have to provide some
unbounded resource pool to get this kind of availability.
IMO, this makes sense to me -- just wanted to make sure the implications were
clear.
> Provide HBase superuser higher priority over other users in the RPC handling
> ----------------------------------------------------------------------------
>
> Key: HBASE-13375
> URL: https://issues.apache.org/jira/browse/HBASE-13375
> Project: HBase
> Issue Type: Improvement
> Components: rpc
> Reporter: Devaraj Das
> Fix For: 1.1.0
>
>
> HBASE-13351 annotates Master RPCs so that RegionServer RPCs are treated with
> a higher priority compared to user RPCs (and they are handled by a separate
> set of handlers, etc.). It may be good to stretch this to users too - hbase
> superuser (configured via hbase.superuser) gets higher priority over other
> users in the RPC handling. That way the superuser can always perform
> administrative operations on the cluster even if all the normal priority
> handlers are occupied (for example, we had a situation where all the master's
> handlers were tied up with many simultaneous createTable RPC calls from
> multiple users and the master wasn't able to perform any operations initiated
> by the admin). (Discussed this some with [~enis] and [~elserj]).
> Does this make sense to others?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
