cloudfoundry
Feature: handle rate limiting of UAA server. Fix #1307
If the UAA server is configured with rate limiting, too many parallel requests result in http-429 results. This will block integration tests, as they create a lot of groups in parallel during initialization. With this pull request, the rate limit configuration is requested from UAA and the status is reported. For integration-tests, the limit can be provided with the new environment variable UAA_API_REQUEST_LIMIT. The value gives the maximum number of calls per second for all calls to the UAA Api. Excess requests are queued until a slot becomes free.
In class integration-test/src/test/java/org/cloudfoundry/IntegrationTestConfiguration.java, some changes from a different pull request are copied to allow integration-test execution.
I've looked at the actual implementation, and chatted with the folks from Reactor. I think we should not expose a public API for rate-limiting. Rate limiting is a very complicated topic, and the Reactor team has declined implementing it for a while.
There are a few core issues with the current implementation. The current implementation does not deal with back-pressure, and it has synchronized blocks that are executed within Reactor threads, which I am not confident about.
I think our primary goal here is to fix #1307; maybe there's something much simpler we can do about the integration tests. I am OK adding some APIs in the integration-test module, even if they are not production-ready, though. Please take a look at #1321 and let me know what you think.
