[
https://issues.apache.org/jira/browse/HBASE-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14997572#comment-14997572
]
stack commented on HBASE-12790:
-------------------------------
bq. I've already pointed out why the round-robining on Connections won't meet
the use case.
[~jamestaylor] Nah. Arguments based on hyperbole and unsubstantiated
'concurrency we see' do not carry any weight hereabouts.
bq. We'll soon have MR jobs intermingled with Phoenix queries and this
Connection-level model doesn't address this.
Just have MR tasks schedule at a lower priority.
It doesn't have to be a 'connection-based' solution. It just can't be a bunch
of new complexity whether a new scheduling tier (My objection has been there
since the first patch was posted back in March), new configurations, or plugin
points that inevitably just rot but meantime the project needs to keep them up
'just-in-case'.
The use case seems to have expanded significantly since this issue began. It
has to be round robin over all ops? We are to chunk-in large writes? That is a
massive undertaking. Suggest you rein in your requirements there [~jamestaylor]
This exposition,
http://blog.cloudera.com/blog/2014/12/new-in-cdh-5-2-improvements-for-running-multiple-workloads-on-a-single-hbase-cluster/,
covers most of what has been discussed above. Would be useful if what is
wanted here in this issue was situated relative to this previous work. It
mentions means of deprioritizing long-running scans (IIRC, results were
murky... worth further investigation) and Scanners have since this citation was
written been redone so they can return after a certain size and/or time
threshold has been crossed. This latter will help mitigate long-running scans
shutting out others. In this new regime, its as though a pure round-robin
scheduler that did not distinguish on any attribute -- group or connection --
could work especially if long-running scans were weighted so they were
scheduled less frequently.
> Support fairness across parallelized scans
> ------------------------------------------
>
> Key: HBASE-12790
> URL: https://issues.apache.org/jira/browse/HBASE-12790
> Project: HBase
> Issue Type: New Feature
> Reporter: James Taylor
> Assignee: ramkrishna.s.vasudevan
> Labels: Phoenix
> Attachments: AbstractRoundRobinQueue.java, HBASE-12790.patch,
> HBASE-12790_1.patch, HBASE-12790_5.patch, HBASE-12790_callwrapper.patch,
> HBASE-12790_trunk_1.patch, PHOENIX_4.5.3-HBase-0.98-2317-SNAPSHOT.zip
>
>
> Some HBase clients parallelize the execution of a scan to reduce latency in
> getting back results. This can lead to starvation with a loaded cluster and
> interleaved scans, since the RPC queue will be ordered and processed on a
> FIFO basis. For example, if there are two clients, A & B that submit largish
> scans at the same time. Say each scan is broken down into 100 scans by the
> client (broken down into equal depth chunks along the row key), and the 100
> scans of client A are queued first, followed immediately by the 100 scans of
> client B. In this case, client B will be starved out of getting any results
> back until the scans for client A complete.
> One solution to this is to use the attached AbstractRoundRobinQueue instead
> of the standard FIFO queue. The queue to be used could be (maybe it already
> is) configurable based on a new config parameter. Using this queue would
> require the client to have the same identifier for all of the 100 parallel
> scans that represent a single logical scan from the clients point of view.
> With this information, the round robin queue would pick off a task from the
> queue in a round robin fashion (instead of a strictly FIFO manner) to prevent
> starvation over interleaved parallelized scans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
