Concurrent Rate Limit returns 503 status when backend server returns 404

Not applicable

Hi, I have concurrent rate limit policy implemented. The policy is included in PreFlow, Post Flow and Default Fault Rule. When our backend server returns 404 status then the concurrent rate limit sends back as 503. Could you please let me know what is wrong and it is strange that concurrent rate limit converts to 503

Regards,

Hemanth K N

0 7 668
7 REPLIES 7

nmallesh
Participant V

Hi @Hemanth,

Kindly include the screenshots of the policies attached, and also a snippet for concurrent rate limit policy.

Yes, it is strange, but we will be able to resolve only if we can reproduce the same issue.

sjm2000
Participant V

Hi,

For me 503 seems correct.

Reason being in first checks the rate limit (which terminates and returns 503), then it checks backend response (which here is 404, not 200 ).

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Regards

Sujith Mathew

I can able to reproduce same. It's definitely a bug in the product (APIRT-2632). I will follow up with Engineering team for a fix. I just bumped up the priority of the issue & We will keep you posted. Please see the workaround for now below.

Remember, It's a best practice to attach concurrent rate limit policy to request, response as well as fault rule (Error flow) ? Looks like concurrent rate limit in fault rule is not working as expected.

Just to work around this issue, Add a condition to the default fault rule concurrent rate limit policy step so that it never executes. I just added a dummy condition like below so that it never executes in error flow to avoid above error.

<DefaultFaultRulename="default-fault"><AlwaysEnforce>true</AlwaysEnforce><Step><Name>Concurrent-Rate-Limit-1</Name><Condition>(response.status.code = '')</Condition></Step></DefaultFaultRule>

You might be wondering what happens to the counter if it never executes in response / error flow ? Remember the ttl attribute that you set in concurrent rate limit policy ? It anyways decrements the counter after certain time. So, We should be good for time being.

Hope above work around helps & we will keep you posted.

You might be wondering what happens to the counter if it never executes in response / error flow ? Remember the ttl attribute that you set in concurrent rate limit policy ? It anyways decrements the counter after certain time. So, We should be good for time being.

If I understand correctly, for this assumption to work when having reasonable concurrent traffic the ttl would need to be set heuristically to avoid problems. More specifically it should be near equal to your 50th percentile response time.

If its too high, you could risk issuing artificial Limit Exceeded errors to valid user requests because the decrement is not happening fast enough. If its too low, you could risk you could risk instability in your backend application because you're decrementing before the connection is truly finished, accumulating additional unexpected load.

Hi @Anil Sagar , Do we have any update for this issue or still need to go with the workaround.

Not applicable

@Anil Sagar

Is there any update on this issue .We are also facing the same issue .We are on 4.17.01 edge-gateway. is the fix expected anytime soon in 4.17.05 ?

regards

arpit

@Hemanth and @ARPIT SHARMA,

Check if you are getting java.lang.IllegalMonitorStateException which eventually leads to 503 Service Unavailable error when you have Concurrent Rate Limit policy and you get a non successful response code for an API. If yes, then this could be the same issue as reported in the community here. That issue has been fixed in the latest Private Cloud Release 4.17.09 .