You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Sergey Shelukhin (JIRA)" <ji...@apache.org> on 2019/05/01 02:27:00 UTC

[jira] [Assigned] (HBASE-22346) scanner priorities/deadline units are invalid for non-huge scanners

     [ https://issues.apache.org/jira/browse/HBASE-22346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Shelukhin reassigned HBASE-22346:
----------------------------------------

    Assignee: Sergey Shelukhin

> scanner priorities/deadline units are invalid for non-huge scanners
> -------------------------------------------------------------------
>
>                 Key: HBASE-22346
>                 URL: https://issues.apache.org/jira/browse/HBASE-22346
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>            Priority: Major
>
> I was looking at using the priority (deadline) queue for scanner requests; what I see is that AnnotationReadingPriorityFunction, the only impl of the deadline function available, implements getDeadline as sqrt of the number of next() calls, from HBASE-10993.
> However, CallPriorityComparator.compare, its only caller, adds that "deadline" value to the callA.getReceiveTime() in milliseconds...
> That results in some sort of a meaningless value that I assume only make sense "by coincidence" for telling apart broad and specific classes of scanners... in practice next calls must be in the 1000s before it becomes meaningful vs small differences in ReceivedTime
> When there's contention from many scanners, e.g. small scanners for meta, or just users creating tons of scanners to the point where requests queue up, the actual deadline is not accounted for and the priority function itself is meaningless... In fact as queueing increases, it becomes worse because receivedtime differences grow.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)