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

Hudson commented on HBASE-29479:
--------------------------------

Results for branch branch-2
        [build #1319 on 
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/]: 
(/) *{color:green}+1 overall{color}*
----
details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/General_20Nightly_20Build_20Report/]


(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]


(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]


(/) {color:green}+1 jdk17 hadoop3 checks{color}
-- For more information [see jdk17 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]


(/) {color:green}+1 jdk17 hadoop 3.3.5 backward compatibility checks{color}
-- For more information [see jdk17 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]


(/) {color:green}+1 jdk17 hadoop 3.3.6 backward compatibility checks{color}
-- For more information [see jdk17 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]


(/) {color:green}+1 jdk17 hadoop 3.4.0 backward compatibility checks{color}
-- For more information [see jdk17 
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/1319/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]


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


(/) {color:green}+1 client integration test for HBase 2 {color}
(/) {color:green}+1 client integration test for 3.3.5 {color}
(/) {color:green}+1 client integration test for 3.3.6 {color}
(/) {color:green}+1 client integration test for 3.4.0 {color}
(/) {color:green}+1 client integration test for 3.4.1 {color}


> QuotaCache is not correctly populated until runs of QuotaRefresherChore
> -----------------------------------------------------------------------
>
>                 Key: HBASE-29479
>                 URL: https://issues.apache.org/jira/browse/HBASE-29479
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Charles Connell
>            Assignee: Charles Connell
>            Priority: Minor
>              Labels: pull-request-available
>             Fix For: 2.7.0, 3.0.0-beta-2, 2.6.4
>
>
> When asked for a QuotaLimiter for a given user, the QuotaCache checks if that 
> user's quota state is cached. If it is, it returns a QuotaLimiter based on 
> the cached information. If not, it inserts default quota state into the 
> cache, and returns a default QuotaLimiter. On the next run of the 
> QuotaRefresherChore, it looks in the {{hbase:quota}} table for the quota 
> settings for every user in the cache. The consequence of this is: from when 
> the QuotaCache is first asked about a user, until the next run of 
> QuotaRefresherChore, the QuotaLimiters for that user are wrong.
> I think it's unacceptable for QuotaCache to return incorrect information. I 
> can see from a code comment that it was implemented this was as a performance 
> optimization, to avoid doing a Get on the quota table in the query handler 
> path. However, the performance consequences of not enforcing quotas can be a 
> lot worse that a few Gets.
> In this ticket I'm adding logic to QuotaCache so it immediately fetches quota 
> information for a user from the quota table any time that user is not in its 
> cache.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to