[
https://issues.apache.org/jira/browse/HBASE-29479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Connell updated HBASE-29479:
------------------------------------
Description:
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.
was:
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 fetches quota information
for a user from the quota table any time that user is not in its cache.
> 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
>
> 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)
