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

Istvan Toth commented on HBASE-29331:
-------------------------------------

There are three ways to fix this:
- Revert the logic to run the chore before returning from 
QuoateCache:get*QuotaState
- Avoid evicting Quota cache entries before they have been initialized at least 
once
- Avoid artifically advancing the clock in the test case.

The first way trades performance for correctness, which is not ideal for the 
quota system.
The second runs the risk of never evicting some entries, if they are only ever 
accessed once.
The third seems to be lowest risk and simplest fix.


> TestDefaultQuota fails because of pseudo-race condition
> -------------------------------------------------------
>
>                 Key: HBASE-29331
>                 URL: https://issues.apache.org/jira/browse/HBASE-29331
>             Project: HBase
>          Issue Type: Bug
>          Components: Quotas
>            Reporter: Istvan Toth
>            Assignee: Istvan Toth
>            Priority: Major
>
> HBASE-28963 changes the QuotaCache logic so that QuotaRefresherChore is not 
> run before returning the Quota object.
> This results in the first quota object returned being a default object, which 
> gets updated by the next  QuotaRefresherChore run.
> Normally, this shouldn't be a problem, as eventually a QuotaRefresherChore is 
> run, and the Quota gets updated to the real value.
> However, in tests the EnvironmentEdgeManager clock is advanced several 
> minutes several times, between trying to execute the operations, which 
> results in the Quota entry always getting evicted before it has has had a 
> chance to get updated, and the test is always using the default Quota object 
> instead of the real one.
> Specifically, this manifests in TestDefaultQuota always failing on my machine 
> (and internal CI hosts).



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

Reply via email to