hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10993) Deprioritize long-running scanners
Date Fri, 18 Apr 2014 04:23:15 GMT

    [ 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

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

View raw message