Alternative to read spike arrest value from a variable

We have a requirement where we are requested not to hard code the spike arrest value. I know that Spike Arrest can be reference using a variable. <Rate ref="some variable" /> For satisfying the requirement currently we are reading the spike arrest value from kvm, reading it to a variable and applying to ref(before spike arrest policy). I know this value can be read from input header etc; but is there a better way to reference the spike arrest value without hard coding it . I am asking for alternative as I felt it does not make sense to have a policy before spike arrest policy

Solved Solved
1 2 576
2 ACCEPTED SOLUTIONS

@Veera Balaji Penugonda , Interesting requirement,

Here is what i think about same,

  • Obviously, you don't want to send data in request using headers / payload during runtime since it's spike arrest & you want API Manager to decide same not the end users who will be consuming APIs.
  • If you are not sending in request means, you need to to either hard code / read from any database like KVM / any other data store.
  • Yes, if you are using KVM you need a policy. I am sure, it's not a performance bottleneck since it only takes a few milliseconds until unless you are optimizing your proxy for few additional TPS.

There is a way to avoid extra policy & get value from reference variable, but not sure how it benefits from performance optimization unless you run some load test. If you are using OAuth to secure your API Proxy, you can create API Product / Developer App / Developer custom attribute which stores spike arrest reference value which will be available as flow variable after OAuth Token / Key verification which you can use in Spike Arrest policy restriction.

That means you need to keep spike arrest policy after OAuth Token / Key verification. You can find related post here.

View solution in original post

Not applicable

Hi @Veera Balaji Penugonda,

I agree with Anil's opinion as API manager should decide these values.

Also, I agree that SpikeArrest policy should be placed as much early as possible in the flow. KVM is an acceptable approach and that means SpikeArrest will become second policy in the flow. Note that KVM brings the flexibility of modifying these values at run-time.

Other approach is build-time approach. One can specify such values as part of the config.json file which in turn will be read by maven plugin and replaces such values as part of the proxy bundle during deployment. Any change in these values as part of the config.json would require proxy re-deployment.

I would suggest to continue with KVM unless there is really a need. Read from KVM shouldn't add much overhead as this policy has been optimised as part of the platform for faster access.

Cheers, Rajesh Doda

View solution in original post

2 REPLIES 2

@Veera Balaji Penugonda , Interesting requirement,

Here is what i think about same,

  • Obviously, you don't want to send data in request using headers / payload during runtime since it's spike arrest & you want API Manager to decide same not the end users who will be consuming APIs.
  • If you are not sending in request means, you need to to either hard code / read from any database like KVM / any other data store.
  • Yes, if you are using KVM you need a policy. I am sure, it's not a performance bottleneck since it only takes a few milliseconds until unless you are optimizing your proxy for few additional TPS.

There is a way to avoid extra policy & get value from reference variable, but not sure how it benefits from performance optimization unless you run some load test. If you are using OAuth to secure your API Proxy, you can create API Product / Developer App / Developer custom attribute which stores spike arrest reference value which will be available as flow variable after OAuth Token / Key verification which you can use in Spike Arrest policy restriction.

That means you need to keep spike arrest policy after OAuth Token / Key verification. You can find related post here.

Not applicable

Hi @Veera Balaji Penugonda,

I agree with Anil's opinion as API manager should decide these values.

Also, I agree that SpikeArrest policy should be placed as much early as possible in the flow. KVM is an acceptable approach and that means SpikeArrest will become second policy in the flow. Note that KVM brings the flexibility of modifying these values at run-time.

Other approach is build-time approach. One can specify such values as part of the config.json file which in turn will be read by maven plugin and replaces such values as part of the proxy bundle during deployment. Any change in these values as part of the config.json would require proxy re-deployment.

I would suggest to continue with KVM unless there is really a need. Read from KVM shouldn't add much overhead as this policy has been optimised as part of the platform for faster access.

Cheers, Rajesh Doda