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

["Hudson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-22346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853583#comment-16853583 ] 

Hudson commented on HBASE-22346:
--------------------------------

Results for branch HBASE-22346
	[build #27 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/27/]: (x) *{color:red}-1 overall{color}*
----
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/27//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/27//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/27//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(/) {color:green}+1 client integration test{color}


> 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
>         Attachments: HBASE-22346.01.patch, HBASE-22346.patch
>
>
> 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)