Javalin: RateLimiter initializing a new executor for every timeunit?

[spinscale]

Describe your question: I was curious about the RateLimiter implementation (especially if the matched path was used to avoid exploding hashmaps in the limiter :-) and took a look at the implementation. Just to make sure I understood the code correctly (my kotlin skills are still bad, sorry :-):

Is there a new thread pool executor created for every TimeUnit enum value, potentially running seven executors in the worst case, that all run a single repeating action?

Also, another minor nit: The current sample in the docs would create a ton of very short lived objects that require GC if an endpoint is hammered with requests. Maybe that rate limiter object should be stored in the context?

[tipsy]

Is there a new thread pool executor created for every TimeUnit enum value, potentially running seven executors in the worst case, that all run a single repeating action?

Yes, that is correct. I considered it unlikely that people would want to use 7 different TimeUnits. Only H/M/S seem relevant, and I doubt most people will want to mix them. I'm not sure if this feature will be used by anyone, so I went with a very simple approach.

Also, another minor nit: The current sample in the docs would create a ton of very short lived objects that require GC if an endpoint is hammered with requests. Maybe that rate limiter object should be stored in the context?

That is true. It doesn't make much sense to generate these objects in the first place, it just looks nicer than Factory.create(ctx, timeunit, numReqs). I doubt these short-lived objects are an issue, but it might be worth looking into.

If it turns out that people like this feature and want to use it, we can spend some time to improve it :)

[tipsy]

@spinscale Do you have any other questions/concerns, or can this be closed?

[spinscale]

I'm good, your answers make perfect sense. Thanks!