Ooops, looks like Alex and I switched to our IDEs at the same time - now there are two PRs :) https://github.com/apache/polaris/pull/3507 I'm open to use one or the other - whichever works best for the community!
On Thu, Jan 22, 2026 at 3:24 PM Jean-Baptiste Onofré <[email protected]> wrote: > Awesome ! Thanks Alex :) > > It helps to see how it could work. > > Regards > JB > > On Thu, Jan 22, 2026 at 2:49 PM Alexandre Dutra <[email protected]> wrote: > > > Hi all, > > > > I just finished a PoC with the Bucket4J extension: > > > > https://github.com/apache/polaris/pull/3506 > > > > I'm not advocating for this change at this point, I just wanted to try it > > out. > > > > Thanks, > > Alex > > > > On Thu, Jan 22, 2026 at 12:10 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > Hi Robert, > > > > > > I was primarily thinking of Bucket4j, as I am not certain the > > > quarkus-bucket4j extension exactly matches our needs. > > > > > > That said, since Guava is already a dependency, if the Guava > RateLimiter > > > meets our requirements, I think it is a strong option as it avoids > > > introducing a new dependency. > > > > > > Regards, > > > JB > > > > > > On Thu, Jan 22, 2026 at 11:57 AM Robert Stupp <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > > Thanks all for the discussion! Bucket4j is certainly an alternative. > > Do you > > > > guys think about the Quarkus-Bucket4j extension or "just" bucket4j > as a > > > > dependency? > > > > > > > > Robert > > > > > > > > > > > > On Thu, Jan 22, 2026 at 9:34 AM Jean-Baptiste Onofré < > [email protected]> > > > > wrote: > > > > > > > > > Hi Robert, > > > > > > > > > > Regarding the rate limiter, I recall advocating for leveraging > > existing > > > > > implementations (such as SmallRye or Bucket4j) during our Quarkus > > > > adoption. > > > > > This discussion seems very similar. > > > > > > > > > > I agree with the proposal to use a "provided" RateLimiter. While > > Guava’s > > > > > RateLimiter is an interesting option, I suggest we also consider > > Bucket4j > > > > > as it is part of the Quarkiverse ecosystem. > > > > > > > > > > Regards, > > > > > JB > > > > > > > > > > On Wed, Jan 21, 2026 at 9:41 AM Robert Stupp <[email protected]> > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > Rate limiting was introduced to Polaris in September 2024 and has > > seen > > > > > > several updates since. Recently, a bug was identified regarding > > how we > > > > > > handle certain logic paths, and a fix has been proposed in a new > > PR. > > > > > > > > > > > > In reviewing the recent PR and the underlying implementation, > I’ve > > > > > > been thinking about a few architectural questions: > > > > > > > > > > > > 1. Correctness and Determinism: > > > > > > Does the current logic fully capture the deterministic properties > > > > > > required by the Token Bucket algorithm? For instance, by not > > > > > > accounting for fractional token regeneration, are we at risk of > > > > > > drifting from expected behavior? > > > > > > > > > > > > 2. Testing Strategy: > > > > > > Would it be beneficial to introduce deterministic clock > > simulations or > > > > > > property-based verification to our test suite? I’m concerned that > > our > > > > > > current reliance on the wall clock might make it difficult to > catch > > > > > > edge cases in a CI environment. > > > > > > > > > > > > 3. Clock Sources: > > > > > > Since the wall clock can move backward and forward, should we > > consider > > > > > > moving toward a strictly monotonic clock to avoid arithmetic > > overflows > > > > > > or "infinite token" scenarios? > > > > > > > > > > > > 4. Leveraging Existing Libraries: > > > > > > Given the complexity of getting concurrency and synchronization > > right > > > > > > for high-throughput rate limiting, would it make sense to explore > > > > > > using Guava’s RateLimiter? Since it's already on our classpath, > > could > > > > > > we benefit from its maturity, optimized synchronization and > > > > > > sub-millisecond precision? > > > > > > > > > > > > I'm also curious to hear your thoughts on whether we should > address > > > > > > these additional areas: > > > > > > * Cold Start: Should we be supporting "warm-up" periods for rate > > > > > limiters? > > > > > > * Contention: Could we reduce synchronization overhead by > > leveraging a > > > > > > more mature implementation's critical paths? > > > > > > > > > > > > Rather than continuing to patch the custom implementation, what > do > > you > > > > > > all think about pausing the development on TokenBucket and > > evaluating > > > > > > a migration to a more established library like Guava? > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > >
