[
https://issues.apache.org/jira/browse/HBASE-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095757#comment-14095757
]
Matteo Bertozzi commented on HBASE-11724:
-----------------------------------------
{quote}Without reading the code, this is ambiguous - what does 0 or 1
specifically mean? what is the default setting? does 0 mean get+scan shared,
and 1 mean separate? is it a float? (it is) I it a sub share of
h.i.s.callqueue.read.share or is it at the "same level"? (it is not).{quote}
Isn't that all explained in the hbase-default doc?
A value of 0 or 1 indicate to use the same set of queues for gets and scans.
any other value is multiplied by the number of read queues that you have.
{quote}(related question - is hbase.ipc.server.callqueue.read.share a float or
is it specifically 0, 0.5 and 1.0 values?){quote}
a float...
{quote}can we get to a place where scan or gets receive no share? What happens
then?{quote}
no, you get at least 1 get queue in case you want lots of more scans. otherwise
the queues are shared.
Basically it does what you expect, "give me more scans" or "give me less scans"
if you want to do the math to specify the right number of queues good for you,
otherwise the will do what is right based on what you specified.
{quote}Need some validation to make sure negative values or other silly values
throw warnings and don't cause problems.{quote}
aside the fact that I don't see validation in any place where we have conf
values, here all the value that you set will result in a valid settings. < 0
will result in 0, > 0 will result in 1
> Add to RWQueueRpcExecutor the ability to split get and scan handlers
> --------------------------------------------------------------------
>
> Key: HBASE-11724
> URL: https://issues.apache.org/jira/browse/HBASE-11724
> Project: HBase
> Issue Type: New Feature
> Components: IPC/RPC
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-11724-v0.patch
>
>
> RWQueueRpcExecutor has the devision between reads and writes requests, but we
> can split also small-reads and long-reads. This can be useful to force a
> deprioritization of scans on the RS.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
