go-tarantool icon indicating copy to clipboard operation
go-tarantool copied to clipboard

Backpressure Retry

Open ice-ares opened this issue 2 years ago • 4 comments

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.

ice-ares avatar Nov 15 '22 12:11 ice-ares

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.

oleg-jukovec avatar Nov 15 '22 14:11 oleg-jukovec

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 avatar Nov 15 '22 14:11 ice-ares

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

ice-ares avatar Nov 28 '22 11:11 ice-ares

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

oleg-jukovec avatar Nov 28 '22 15:11 oleg-jukovec