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

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

2019-06-10 Thread Josh Elser (JIRA)



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

Josh Elser commented on HBASE-22346:


Not sure if you still need/want it, but I removed this branch and pushed a tag 
(feature-HBASE-22346-tag) instead. If this is just one commit, I reckon that 
precommit should give you the necessary testing capabilities?

Trying to clean up space on Jenkins. Shout if you want this back :)

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

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

2019-06-10 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #38 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/38/]: 
(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/38//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/38//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/38//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)

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

2019-06-09 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #37 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/37/]: 
(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/37//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/37//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/37//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)

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

2019-06-09 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #36 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/36/]: 
(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/36//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/36//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/36//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)

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

2019-06-08 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #35 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/35/]: 
(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/35//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/35//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/35//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)

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

2019-06-07 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #34 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/34/]: 
(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/34//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/34//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/34//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)

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

2019-06-06 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #33 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/33/]: 
(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/33//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/33//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/33//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)

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

2019-06-05 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #32 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/32/]: 
(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/32//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/32//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/32//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)

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

2019-06-04 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #31 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/31/]: 
(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/31//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/31//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/31//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)

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

2019-06-03 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #29 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/29/]: 
(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/29//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/29//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/29//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)

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

2019-06-03 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #30 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/30/]: 
(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/30//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/30//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/30//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)

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

2019-06-01 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #28 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/28/]: 
(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/28//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/28//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/28//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)

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

2019-05-31 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/HBASE-22346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

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

2019-05-31 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #26 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/26/]: 
(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/26//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/26//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/26//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)

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

2019-05-30 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #25 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/25/]: 
(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/25//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/25//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/25//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)

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

2019-05-29 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #24 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/24/]: 
(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/24//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/24//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/24//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)

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

2019-05-28 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #23 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/23/]: 
(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/23//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/23//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/23//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)

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

2019-05-27 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #22 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/22/]: 
(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/22//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/22//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/22//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)

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

2019-05-26 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #21 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/21/]: 
(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/21//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/21//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/21//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)

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

2019-05-25 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #20 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/20/]: 
(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/20//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/20//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/20//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)

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

2019-05-24 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #19 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/19/]: 
(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/19//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/19//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/19//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)

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

2019-05-23 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #18 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/18/]: 
(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/18//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/18//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/18//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)

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

2019-05-22 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #17 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/17/]: 
(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/17//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/17//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/17//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)

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

2019-05-21 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #16 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/16/]: 
(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/16//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/16//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/16//JDK8_Nightly_Build_Report_(Hadoop3)/]


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


(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for 
details|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/16//artifact/output-integration/hadoop-2.log].
 (note that this means we didn't run on Hadoop 3)


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

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

2019-05-20 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


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

details (if available):

(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/15//console].




(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/15//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/15//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)

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

2019-05-19 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #14 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/14/]: 
(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/14//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/14//console].


(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/14//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)

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

2019-05-18 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #12 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/12/]: 
(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/12//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/12//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/12//console].


(/) {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)

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

2019-05-16 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #11 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/11/]: 
(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/11//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/11//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/11//console].


(/) {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)

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

2019-05-15 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #10 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/10/]: 
(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/10//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/10//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/10//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)

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

2019-05-15 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #9 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/9/]: 
(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/9//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/9//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/9//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)

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

2019-05-14 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #8 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/8/]: 
(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/8//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/8//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/8//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)

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

2019-05-13 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


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

details (if available):

(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/7//console].




(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/7//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/7//console].


(/) {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)

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

2019-05-11 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #6 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/6/]: 
(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/6//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/6//console].


(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/6//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)

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

2019-05-11 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #5 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/5/]: 
(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/5//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/5//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/5//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)

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

2019-05-10 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #4 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/4/]: 
(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/4//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/4//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/4//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)

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

2019-05-09 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


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

details (if available):

(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/3//console].




(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/3//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/3//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)

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

2019-05-08 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #2 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/2/]: 
(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/2//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/2//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/2//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)

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

2019-05-07 Thread Hudson (JIRA)



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

Hudson commented on HBASE-22346:


Results for branch HBASE-22346
[build #1 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/1/]: 
(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/1//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/1//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/1//JDK8_Nightly_Build_Report_(Hadoop3)/]


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


(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for 
details|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22346/1//artifact/output-integration/hadoop-2.log].
 (note that this means we didn't run on Hadoop 3)


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

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

2019-05-06 Thread HBase QA (JIRA)



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

HBase QA commented on HBASE-22346:
--

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
56s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  7m 
 8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
48s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
8s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  1m 
27s{color} | {color:red} hbase-server: The patch generated 5 new + 94 unchanged 
- 1 fixed = 99 total (was 95) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  6m 
32s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
13m 53s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  6m  
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m  
2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}160m  7s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
24s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}218m 28s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base: 
https://builds.apache.org/job/PreCommit-HBASE-Build/253/artifact/patchprocess/Dockerfile
 |
| JIRA Issue | HBASE-22346 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12967980/HBASE-22346.01.patch |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux f3493376e302 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb 
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 67c937fa92 |
| maven | version: Apache Maven 3.5.4 
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle | 
https://builds.apache.org/job/PreCommit-HBASE-Build/253/artifact/patchprocess/diff-checkstyle-hbase-server.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/253/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results |

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

2019-05-01 Thread HBase QA (JIRA)



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

HBase QA commented on HBASE-22346:
--

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
31s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
52s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  1m 
17s{color} | {color:red} hbase-server: The patch generated 6 new + 94 unchanged 
- 1 fixed = 100 total (was 95) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
31s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 38s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}137m 
33s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
21s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}178m 23s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base: 
https://builds.apache.org/job/PreCommit-HBASE-Build/226/artifact/patchprocess/Dockerfile
 |
| JIRA Issue | HBASE-22346 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12967572/HBASE-22346.patch |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 3bcbdd583a67 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb 
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 4379fe4ad3 |
| maven | version: Apache Maven 3.5.4 
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle | 
https://builds.apache.org/job/PreCommit-HBASE-Build/226/artifact/patchprocess/diff-checkstyle-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/226/testReport/ |
| Max. process+thread count | 4915 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |

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

2019-04-30 Thread Sergey Shelukhin (JIRA)



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

Sergey Shelukhin commented on HBASE-22346:
--

[~stack] [~mbertozzi] does this make sense to you? preserves the old behavior 
with low/no overhead when unset. We will probably run this for meta only on our 
cluster and see how it goes.

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

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

2019-04-30 Thread Sergey Shelukhin (JIRA)



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

Sergey Shelukhin commented on HBASE-22346:
--

cc [~mbertozzi] was adding the number to received time intentional?

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

42 matches

Mail list logo