-
Notifications
You must be signed in to change notification settings - Fork 58
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
Backpressure Retry #228
Comments
This is easy to implement with read-only requests, but difficult with write-requests: it's harder to make a decision. It seems to me that this should be done on a client code that knows more information: for {
if err := pool.Do(updateRequest); err != nil {
if !some_condition(err) {
break
}
// else some other logic
}
} It's hard to guess But we are open to suggestions about the API if it looks universal. |
thats my point, to have a strategy pattern there, with 3 implementations, None, Default, Custom (user implements it) None is what we have now. Default would be 90% of the use cases. Because people just need to write some data to the database, and they only care about data specific errors I.E. conflicts, tuple found/not found, etc. So rather than having developers create each a almost identical version of:
|
@oleg-jukovec @DifferentialOrange would you guys be OK with accepting a contribution(a PR) on this ? |
I would like to see a public API before the implementation. It will help reduce the work. |
Can we have a back pressure retry mechanism for errors that the user of the library is not responsible for. I.E. if there's some server issue, if instance is no longer writable, etc.
This would be very needed in connection pool, where we could retry to another instance in the pool.
The text was updated successfully, but these errors were encountered: