-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for a relay based retry #98
Comments
Hello @thehesiod ! That's a very interesting proposal. One thing that is missing for me - is why would that be useful? Maybe you can share any additional context, in which environment such behaviour would be nice to have? In my understanding, usually caller doesn't need to have two requests for the same resource in parallel, because you would create an additional load to the server. Also I believe that supporting this feature would be a heavy lift for aiohttp_retry, the implementation would need to be completely different from what it is now. I would like to keep package thin. So I would like not to support this as long as this feature is very rare in need. |
it is in fact very useful. we use it in several places, like against open search where 1% or less of there is service degradation. what if the service you're calling is degraded. each call you make times out, with a sleep between calls. this makes the server eventually report a 5xx because the backend call failed several times. if instead it's timed and retried correctly, the first call may eventually succeed since it was never cancelled. also if the initial timeout is selected well, 99% of the time it is never retried. of course it needs to be used judiciously |
anyhow just a suggestion used in many places. feel free to close as we have our own internal implementation with exponential back off, jitter, etc |
actually this reminds me, i saw an impl in aiohappyeyeballs as well, which led me to the idea to expose it in somewhere more appropriate |
I would not do this myself, but if somebody will issue a PR I'm happy to merge |
meaning you do a request, and if after N seconds it doesn't finish, you start another request, and keep repeating up to N requests in parallel. First one that finishes wins, and you cancel the others. With jitter/exp backoff, etc support
The text was updated successfully, but these errors were encountered: