Skip to content
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

Open
ice-ares opened this issue Nov 15, 2022 · 4 comments
Open

Backpressure Retry #228

ice-ares opened this issue Nov 15, 2022 · 4 comments

Comments

@ice-ares
Copy link

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.

@oleg-jukovec
Copy link
Collaborator

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 some_condition() from the library side. That's why we're not even trying to do it.

But we are open to suggestions about the API if it looks universal.

@ice-ares
Copy link
Author

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:

fun some_condition(err error) bool {
   return err is not tuple not found || err is not tuple found ...
}

@ice-ares
Copy link
Author

@oleg-jukovec @DifferentialOrange would you guys be OK with accepting a contribution(a PR) on this ?

@oleg-jukovec
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants