Aleksandr Shamukov

Hi Dino! Thanks for the answer! Sounds great, hope I'll come back soon with PR! 🙏

Hi Dino! It's me again) Just would like to say, that if some of release-cutting work is "forkable", I could also help)

Not an answer, just a few related links: https://github.com/spring-projects/spring-retry/issues/154 https://github.com/spring-projects/spring-retry/pull/176

@dsyer Hello Dave! Thanks for the rebase. > The way we normally solve it in Spring projects is to provide a wrapper for the executor that has to be supplied...

> I give that solution 👍 Thanks, Artem!) Just to double-check: are you agree, that in this situation, copy-pasting is better than extracting `DelegatingContextExecutor` to somewhere like spring-core, and parametrizing...

> Do you have something to take a look already? This is an attempt ;) https://github.com/ashamukov/spring-security/pull/1

Thanks, Artem! > Let's raise an issue The issue: https://github.com/spring-projects/spring-framework/issues/23876

Hi Darius! Could you please provide an example of detailed usage scenario? Now, I'm concerned about one thing: public API of RetryOperations is synchronous, because it returns values directly from...

> I was looking into another retry library, that takes an asynchronous approach. It's described here: https://www.nurkiewicz.com/2013/07/asynchronous-retry-pattern.html @DariusX , thanks for the link, haven't seen it before

Dave, thank for prototype, this reusing of existing api looks very elegant for me. Now, I'm thinking about, how to avoid Thread.sleep'ing in backoffs. The only way I see now...