Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Configurable back-pressure strategy #8533
If the client gets overloaded with requests, instead of applying back pressure out of the box, an OverloadException is thrown.
This is a very unintuitive exception to deal with and gives a bad out of the box experience since one now needs to litter HZ interaction with overload handling code.
The intuitive way to deal with this is not immediately expose this exception to the end user but apply some back-pressure using e.g. randomized exponential backoff (so delays). Only when the delays have exceeded some time threshold, the exception is thrown to the user. This is the way the server deals with it.
Using an overload policy a user can also realize the current behavior where an OverloadException is thrown at the moment it happens and he can add backoff logic at every HZ interaction himself; although I question if this the most practical approach.
Apart from an painful API , these OverloadException are pretty expensive due to stacktraces being created. So if back pressure isn't handled correctly, the client could be bogged down by gc. And although it might provide some back pressure, I doubt this is desired behavior.