[
https://issues.apache.org/jira/browse/HBASE-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973799#comment-13973799
]
Matteo Bertozzi commented on HBASE-10993:
-----------------------------------------
{quote}That is a good way of putting it. Should this method name be changed to
reflect what its actually doing then? getPriorityQueue? Or should getDeadline
be called getSubPriority or getMinorPriority and getMajorPriority.{quote}
Since we don't have any other kind of priority at the moment (aside HI,
REPLICATION, NORMAL) I guess we can keep the getPriority() name for the queue
selection.
The "deadline" name is describing exactly what is doing, since it will tell you
the when the request should be dispatched Nmsec from now. If you look at the
priority queue, it is ordered by the maximum time that a call can wait.
{quote}Maybe you don't want to change getPriority because this queue selection
is kinda hacky and could go away? If it did, how then would these two different
priorities interact?{quote}
When we will switch to a user-based scheduler, replication and meta will be two
user with more "share" than the others. Each user will have its own "scheduler"
where you can plug/compose the policies e.g. FIFO, Type-Based
(Writes-Prioritezed or Read-Prioritized) and so on.
The priority that you are thinking about is probably the unix nice priority -20
+20, which is the one that the user may force on a request to prioritize it.
think about a user running two apps, that are both doing put and get but one
can be "slower" than the other, the requests are going in the same user/queue
but you can set which of the two requests can be "delayed" a bit
> Deprioritize long-running scanners
> ----------------------------------
>
> Key: HBASE-10993
> URL: https://issues.apache.org/jira/browse/HBASE-10993
> Project: HBase
> Issue Type: Sub-task
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Priority: Minor
> Fix For: 1.0.0
>
> Attachments: HBASE-10993-v0.patch, HBASE-10993-v1.patch
>
>
> Currently we have a single call queue that serves all the "normal user"
> requests, and the requests are executed in FIFO.
> When running map-reduce jobs and user-queries on the same machine, we want to
> prioritize the user-queries.
> Without changing too much code, and not having the user giving hints, we can
> add a “vtime” field to the scanner, to keep track from how long is running.
> And we can replace the callQueue with a priorityQueue. In this way we can
> deprioritize long-running scans, the longer a scan request lives the less
> priority it gets.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
