[jira] [Commented] (HBASE-4441) Revisit QOS

["Andrew Purtell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108066#comment-13108066 ] 

Andrew Purtell commented on HBASE-4441:
---------------------------------------

bq. Do we want to support different priorities for different tables/users (when security's enabled)/operations?

I've been thinking about this lately too. I think we do. For managing policy that maps pretty well to security (users and groups), hierarchical token bucket could be a reasonable option.

Admission control across the whole cluster is a larger challenge. How does QoS at the HBase layer translate to QoS at the HDFS layer (or not)? Should accesses from a MapReduce job have a different priority than direct API access?

> Revisit QOS
> -----------
>
>                 Key: HBASE-4441
>                 URL: https://issues.apache.org/jira/browse/HBASE-4441
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.94.0
>
>
> Currently we have a simple QOS model where requests to user tables are using one set of handlers and requests to catalog tables and other administrative functions are using another set. I'm wondering if it's worth expending this model:
>  - Do we want to support different priorities for different tables/users (when security's enabled)/operations?
>  - Do we want finer granularity?
> There's also issues like HBASE-4280 that exposes a case where RS communicate between each other and can potentially deadlock if some slowness is going on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira