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
> > > > >
> > > >
> > >
>

Reply via email to