Re: Allowing clients to set priorities

I think option one is interesting if we are able to make our theadpools work more like Java executors: there is a reservation of core threads always available, and another limit where a pool can dynamically create more handlers up to some max and terminate when unused. This addresses the

Re: Allowing clients to set priorities

An interesting discussion indeed. "It is related to PHOENIX-938, but also had this desire back in the days at Flurry, I recall us always wishing for a way that we could reserve a group of handlers for specific users or tables." Could you tell more about what you wished you had at that moment if

Re: Allowing clients to set priorities

On Fri, Apr 22, 2016 at 3:41 PM, rahul gidwani wrote: > ... > For the exposing priority to the client I was thinking this work goes > into OperationWithAttributes or Operation we can add a setPriority() > and getPriority() and by default they are set to normal priority >

Re: Allowing clients to set priorities

I like the idea of reservations. So in this sort of scheme, there would be separate handler pools and a (hopefully, dynamic) configuration to route requests to a specific pool? Or maybe a default configuration set by the site file as done today, but with a runtime facility for adding more handler

Re: Allowing clients to set priorities

Sure: For the first item. Yes that was implemented but there were a few issues. It is related to PHOENIX-938, but also had this desire back in the days at Flurry, I recall us always wishing for a way that we could reserve a group of handlers for specific users or tables. The other issue with

Re: Allowing clients to set priorities

A few things: + Our Matteo reminded me of the HBASE-11048 "Support setting custom priority per client RPC"/PHOENIX-938 "Use higher priority queue for index updates to prevent deadlock" work which adds in a factory so clients can do their rpccontroller. You'd build on this or controllers will

Re: Allowing clients to set priorities

Sure sorry didn't provide a good example. There are two situations where I have thought this feature might be useful. Maybe more... 1. For something like Phoenix, there are situations where you want certain operations for tables / users to always have handlers available to do work. For

Re: Allowing clients to set priorities

This is interesting idea. Sorry if I missed some context - what's the primary incentive here? What's examples of those categorized thread pools? Sounds intersecting a bit with HBASE-15136 (deadline scheduling for RPC requests) in the area of rpc

Re:Re: Allowing clients to set priorities

using this feature, we can set priority for different request, sounds useful At 2016-04-21 14:21:15, "Stack" wrote: >On Wed, Apr 20, 2016 at 1:47 PM, rahul gidwani >wrote: > >> I was wondering if people would be interested in allowing the client

Re: Allowing clients to set priorities

On Wed, Apr 20, 2016 at 1:47 PM, rahul gidwani wrote: > I was wondering if people would be interested in allowing the client to > specify priorities? I really think we are good responsible adults and wont > abuse this feature. :) > > This would not just be for one

Allowing clients to set priorities

I was wondering if people would be interested in allowing the client to specify priorities? I really think we are good responsible adults and wont abuse this feature. :) This would not just be for one particular operation but all operations. I'll make it feature complete. As for batch