Layer7 API Management

I'd like to be able to have a counter that's shared across a cluster. 

So for example

"my-cluster-counter"

Then I'd like to be able to increment this variable in any request, and have it updated cross cluster, and allow for further increments later in the same request.

Is there anyway to do this?

Note that I have multiple situations where I'd like to do the above, and haven't seen anything that clearly does this.

I'm familiar with the Apply Throughput Assertion, but find it doesnt work for this use case, as I want a "Custom" variable name, but this can only be incremented once per request, and doesn't seem to allow inspection of the current value.... The only way I can see to see the current value is to try and "Apply Throughput", but since you can only do this once per request, I can't do it a second time, when I actually have calculated a value to increment it by.

Hi 

You should be able to this have a look at the following thread 

Need to update cluster wide properties for service with RESTman service 

Regards 

Dirk 

Sorry for the late reply, and thanks for the feedback.. The only thing about the suggested solution is that it requires you to know or store the GOID for the cluster property, but I want to create dynamic bucket names for things, based of user groups, user ids, and other considerations, so if I create a new cluster property on the fly, I'd need to store the GOID of it somewhere, which I think is a chicken/egg problem?

Currently I'm using 2 "Apply Throughput Assertion" asserts in a row, one to reset it, and one to set it to a value, then I query that for value modified in the last "min", and it seems to stick around.

Basically if there was some way to query "Apply Throughput Assertion" for the actual current value, then I'd be good!

Hi Brad,

You may try Query Throughput Quota Assertion,

Query Throughput Quota Assertion - CA API Gateway - 9.4 - CA Technologies Documentation 

Regards,

Mark

I've tried using that, and it doesnt seem to work consistently. I've reviewed what I'm doing, and think I'm using "Apply Throughput Assertion" in a non standard way, which is probably the root cause of my issues.

Most people would call this before routing the request to some other web server, but in my case the response from the web server defines what the rate limiting should be. This is to make it easy for any developer of our endpoints to define rate limiting for themselves, without having to make any changes to Layer7.

So I get response headers back from the routed endpoint that say what the max per minute should be, and other values that define the key to be used for the bucket name

e.g. The following response headers could come back

USAGE_COUNTER_TYPE: USER

ALLOWED_USAGE_PER_MINUTE: 10

So for me, if this request came from "/test/me" endpoint, from user 52, the "counter id" would be calculated as something like the following, which is unique for this endpoint and user:

throttle.endpoint./test/me.by.user.52

and then max quota would be set to "10"

Since I only get this info from the routed endpoints response, I have to do my "Apply throughput" after the routed response, and then during the next request, compare my max and current counter then. If the count is exceeded then, then I fail the request before it's routed.

In theory, this should work, and does basically work - except that it seems that sometimes the "counters" dont expire - they seem to live past a minute, and wont expire until I "Apply throughput" one more time. 

So my counter should have expired, and then I have to do one more request before it's refreshed.

I've tried with this with the "Scalability" set to "Consistency" to ensure it wasn't a caching issue, but that didnt seem to help

I am not sure if I understand it correctly, it sounds like your use case is more likely about how to reset the throughput quota.

The Apply Throughput Quota assertion has a Reset option might meet your needs. For more details, you may refer to,

Apply Throughput Quota Assertion - CA API Gateway - 9.3 - CA Technologies Documentation 

Regards,

Mark