Michał Szynkiewicz

https://ris.utwente.nl/ws/files/5129182/classification_of_service.pdf

CC @mswiderski @vsevel

@mswiderski I wanted a place to specifically discuss failover

for me, it's outside of the scope of Stork. The client library (that uses Stork) can choose to ask for a next service instance and do a retry, and if...

But there's also the client library. Which knows better the concurrency model (knows which thread/event loop should handle a retry), has the knowledge which operations are idempotent, etc. @vsevel can...

Yes it does, you can choose on which exceptions you want to retry

At this point, I see `@Retry` as the correct way moving forward. But we have to keep an eye on whether it's enough to cover all the use cases.

@Ladicek what gains do you see in that? There would have to be another annotation to mark an operation as idempotent/retriable, right? There is one thing I'm afraid the MP...

Stork itself is purely programmatic but users won't rather use it directly.

We would have to experiment to check how doable it is but: would a (quarkiverse?) extension that would alter all the clients to apply retries according to defined criteria work?...