#12556 Implement adaptive request throttling on HTTP 429 (Too Many Requests) responses - #12587
#12556 Implement adaptive request throttling on HTTP 429 (Too Many Requests) responses#12587Binabh wants to merge 7 commits into
Conversation
|
Nice work on this, the shape of the solution looks right to me: the per-bucket state is well isolated in Besides the rebase (there are conflicts due to recent work), there are five things I'd like to sort out before merge. The first four are about the defaults rather than the implementation, but together they mean that a single 429 from a remote server can freeze the application with nothing showing up anywhere.
One documentation fix while you're in there: The smaller ones I've left inline: the backoff being reset rather than decayed on success, and the retry loop on the native image path. |
|
@offtherailz thank you for your feedback. I will start working on your suggestions |
|
@offtherailz I have updated the defaults as you mentioned and changed the behavior for |
|
I tested this branch against a server that actually rate-limits, and there are two things worth raising before we go further.
2. Done properly, requires too much complicated work Expecially because the APIs do not expose a way to work with prioritization of tiles. So I'd block this PR for the moment. We have to review the plan before to proceed. |
|
@offtherailz Sorry for that. I tested using the 429 emulation python server that I mentioned in PR description. I will try this on real service and test if its blocking other functionality like login also. For second time I focused my manual verification on cesium single tile load and that default have been properly stored only which is mistake on my side. |
Description
RateLimitManagerand using it in axios interceptorsloadFunctionand also for cesiumPlease check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
Issue
What is the current behavior?
#12556
What is the new behavior?
Mapstore correctly reads Retry-After header in case of 429 response and handles accordingly.
Breaking change
Does this PR introduce a breaking change? (check one with "x", remove the other)
Other useful information
To test all of the features implemented just having a running Geoserver may not be enough. For testing purpose we can start a simple proxy server in front of Geoserver to apply rate limits. Python proxy server used:
rate_limit_server.py