hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ramkrishna vasudevan <ramkrishna.s.vasude...@gmail.com>
Subject Re: Scan priority based on type of request origin
Date Thu, 28 May 2015 06:48:16 GMT
Atleast in trunk it uses SimpleRPCScheduler and internally it tries to use
the Priority based queue so that based on the deadline set for every
request it can schedule the highest priority RPC calls.

I would think that your current requirement may fit with the existing one?
Except that those calls should be given higher prioirty or rather a
deadline such it is scheduled first?

On Thu, May 28, 2015 at 12:14 PM, Anoop John <anoop.hbase@gmail.com> wrote:

> We have pluggable RPC scheduler now.  See config
> 'hbase.region.server.rpc.scheduler.factory.class'
>
> By default a SimpleRpcScheduler is in use and there as you said, there are
> prioritization for super user.  Other prioritization is based on the RS
> side method prioritization based on annotation.
>
> You can see how/whether u can have a custom RPC scheduler and queuing
> mechanism using which you can fulfill this.
>
> -Anoop-
>
> On Thu, May 28, 2015 at 11:56 AM, ashish singhi <ashish.singhi@huawei.com>
> wrote:
>
> > Hello folks.
> >
> > We had a customer scenario to support scan priority based on type of
> > request origin. Consider the scenario , where in n number of scan
> requests
> > are generated from different clients. Some of these requests are high
> > priority as they are originated from high privileged users OR from data
> > viewer Web UI etc. Such request should not wait and must finish execution
> > at the earliest compare to other requests.
> >
> > We went through the code and found that HBase support for de-prioritizing
> > long running scanner(HBASE-10993) and providing super user rpc requests
> > higher priority comparing to other users(HBASE-13375). So this means
> apart
> > from super user all other user request will be treated as same and with
> > normal QOS.
> >
> > Let us know if there are any existing solutions already available which
> > may be we are missing.
> >
> > If implementing this make sense , we can implement this in community.
> >
> > Regards,
> > Ashish Singhi
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message