[ 
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)

Reply via email to