[
https://issues.apache.org/jira/browse/HBASE-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973777#comment-13973777
]
stack commented on HBASE-10993:
-------------------------------
+ * @return Deadline of this request. 0 now, otherwise msec of 'delay'
Ok. I was confused about 'deadline' -- I kept thinking it a timer that was
running over the rpc -- and now I think I understand (and see why it is ok to
have it in the PriorityFunction Interface).
Why call getPriority rather than add this new getDeadline call?
Otherwise, skimmed the patch. LGTM.
How we know if it is working [~mbertozzi] -- or how you think we will be able
to observe that it is operating well on a cluster?
Good stuff.
> 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)
