Defaults vs custom values in attribute

[migig]

I don't understand how the default limits are used.

I always throttle specific actions, using the attribute. I don't do this globally. I want to define custom limits every time I use the attribute e.g. [EnableThrottling(PerFoo=123)].

But there are also defaults set in the global filter. I wish I didn't need to specify defaults, but the constructor wants them. Because of this my limits often conflict and I get unexpected results.

So is it safe to do something like this:

... new ThrottlingFilter( ...
    Policy = new ThrottlePolicy(perSecond:0, perMinute:0, perHour:0, perDay:0, perWeek:0) {
    ...

...and then set my real values on the attribute? I noticed that some of these override the others.

[stefanprodan]

Yes setting the defaults to 0 should work, the default values supplied in the constructor applies to actions that don't have the EnableThrottling attribute, or when you've missed to supply a PerFoo rate in the attribute.
So if the default policy has a perDay limit, and the EnableThrottling doesn't have it, then the perDay limit from ThrottlePolicy constructor will be used.
If all your action have EnableThrottling with every PerX specified then none of the constructor values will apply.

[migig]

Okay that makes good sense.

But what happens, for example, if I want to throttle an action by day. In the attribute, is it enough to specify [EnableThrottling(PerDay = 123)], or must I also specify for PerSecond = and PerHour = as well - to override the 0 value in the defaults?

[stefanprodan]

No need to specify those. You need to put the rate types you want to enable in the constructor and use them in attribute. The 0 value should disable the rate limit type, please make a test and let me know.

[migig]

"You need to put the rate types you want to enable in the constructor"... I assume you mean the ctor of the global filter. It's for a big project, so we "enabled" all of them to 0.

Okay I tested and it seems to work, but we have many places where it's used, and I'm trying to go through many combinations to see what happens.

[migig]

It's a pity this isn't on the main docs, so for anybody else who wants to know, here is my understanding:

• The global filter takes rate limits. These are the defaults.
• The defaults are used if you don't specify custom rate limits in the [EnableThrottling] attribute.
• There are various ways to do throttling. If you prefer to specify custom limits on your attributes, and never rely on defaults, then you must set 0 as the default for all rate limits. So you do this: Policy = new ThrottlePolicy(perSecond:0, perMinute:0, perHour:0, perDay:0, perWeek:0) { .... Then specify a rate limit in the attribute, for example: [EnableThrottling(PerHour = 10)].
• If you take this approach, then the custom rate limits will override the defaults. But also, if your attribute is for e.g. [EnableThrottling(PerHour = 10)] then it not only overrides the perHour: default, but also ignores the perSecond: and perMinute: defaults. This means you don't need to specify custom values for all limits, only the one you are interested in. You don't need to do this: [EnableThrottling(PerSecond = x, PerMinute = y, PerHour = 10)].

Please correct anything if it's wrong? I'll update more when I have tested more.

[stefanprodan]

You are right, this is the intended behavior. I must find a better way to enable/disable limit types.
If you don't specify a rate limit type when you register the filter, even if you specified that type in the attribute it will get ignored.

ThrottlePolicy(perSecond:0, perMinute:0)
[EnableThrottling(PerHour = 10)]

In the example above, PerHour will get ignored.

Thanks for running these tests.

[migig]

Oops, so I misunderstood... 😄

In your example I thought the PerHour will be used, but you say it will be ignored (because it has no corresponding default in the filter). So that means that there will be "maximum" throttling for that attribute, because PerHour is ignored, and everything else is 0?

Sorry, I am maybe a bit "slow" (I've been throttled)...

I agree we should think what is a good way to handle this use case. Or keep it as it is, but make a "formal" documentation for it...