[
https://issues.apache.org/jira/browse/HBASE-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell resolved HBASE-9673.
----------------------------------------
Resolution: Incomplete
> Request priority revamp
> -----------------------
>
> Key: HBASE-9673
> URL: https://issues.apache.org/jira/browse/HBASE-9673
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Michael Stack
> Priority: Major
>
> Currently in the server we have three (four?) queues ranging from Normal (0)
> to High priority (100) with Replication priority falling between the two.
> Priority is determined by introspecting the incoming invocation to pull out
> which region is targeted by the query and/or to read a 'priority' annotation
> that is on the invocation's method -- e.g. closeRegion/openRegion have
> @QosPriority(priority=HConstants.HIGH_QOS) These annotations are awkwardly
> on the java implementation, not on the protobuf Service.
> The current means of introspection determining priority running the silly
> guava function is costly done on each call. The annotations being on the
> java implementation rather than on the pb Service or in the pbs themselves
> requires somersaults extracting priority. If they were on the latter, then
> they would be more readily available down in rpc where invocation/scheduling
> is done.
> There is no way currently for a mapreduce task to tell hbase it is a low
> priority query nor for a webservice coming in the door to say I need a bit of
> info now -- and I don't care who you push aside.
> A suggestion of [~eclark]'s is that we just have the client set the priority.
> This has much merit. We could keep it down low just do what the server
> currently does -- the introspection, annotations -- on client side and have
> it then set the priority into the request header where it will be readily
> available on the server when it is trying to figure what to do w/ the
> incoming call (high, low, or in-between).
> We could even expose this in our API.
> Above is about revamp of how the server figures the static priority of a call
> (HBASE-9612 actually adds priority to the RpcController and into the
> RequestHeader). Server could just respect the client priority for now.
> Later we'd want the server to adjust priorities based off what it thought of
> the user -- trusted or an alien -- as well as factor in its current load. An
> overloaded server might reject low priority calls (Had a good chat on QoS w/
> [~toffer] about QoS at the corner of Van Ness and Market last night).
> Later calls might come w/ an advertised SLA. The server might reject calls
> it thought it could not service in time rather than take on more load (based
> off history of similarly sized queries, etc.).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
