[
https://issues.apache.org/jira/browse/HBASE-13686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552932#comment-14552932
]
Matteo Bertozzi commented on HBASE-13686:
-----------------------------------------
can you post the patch on review board, it is not short. so it will be easier
to review there.
can we lose one level and maybe some fields? having the RateLimiter extended by
RefillStrategy or similar. we are going to have tons of those objects around if
you starting configuring it by user.
what is the point of the AtomicLong in refill strategy we are under lock when
we call that code.
can we go back to external times? otherwise tests must sleep, and aside the
slowness they will be always flaky
> Fail to limit rate in RateLimiter
> ---------------------------------
>
> Key: HBASE-13686
> URL: https://issues.apache.org/jira/browse/HBASE-13686
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.1.0
> Reporter: Guanghao Zhang
> Assignee: Ashish Singhi
> Fix For: 2.0.0, 1.2.0, 1.1.1
>
> Attachments: HBASE-13686.patch
>
>
> While using the patch in HBASE-11598 , I found that RateLimiter can't to
> limit the rate right.
> {code}
> /**
> * given the time interval, are there enough available resources to allow
> execution?
> * @param now the current timestamp
> * @param lastTs the timestamp of the last update
> * @param amount the number of required resources
> * @return true if there are enough available resources, otherwise false
> */
> public synchronized boolean canExecute(final long now, final long lastTs,
> final long amount) {
> return avail >= amount ? true : refill(now, lastTs) >= amount;
> }
> {code}
> When avail >= amount, avail can't be refill. But in the next time to call
> canExecute, lastTs maybe update. So avail will waste some time to refill.
> Even we use smaller rate than the limit, the canExecute will return false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
