Non-suspending variant of Resilience

[vladimirfx]

The main use case is JVM with virtual threads:

Resilience is a handy tool for interaction with external systems. It works quite well in Android and Coroutines-based JVM backend projects. But most of the backend projects are blocking in nature. Most of the usual magic like AOP is not working well with suspend functions.
Until JDK 21, blocking threads for tasks as retry calls is considered bad practice because of the platform nature of threads. Now we have virtual threads that in nature, are very similar to coroutines and can be safely blocked with resilience operations.

What do you think about the non-suspending variant of Arrow Resilience?

[nomisRev]

@vladimirfx, I am absolutely open for it, I expect Loom to also play a important role in Kotlin/JVM (I expect 99% of Spring users to use Loom, not coroutines).

However, I am not entirely sure yet where it would belong. Almost everything in Fx could be ported to Loom. So I am including to build it outside of Arrow, or in a standalone repository (as we're doing for all new projects).

A lot of loom stuff hasn't been explored for Kotlin, but I wrote a fun <A> runLoom(context: CoroutineContext = EmptyCoroutineContext, block: suspend () -> A): A function for a non-public project and it was working great. Which could also be an alternative, since it works for all suspend code not just Schedule.

What do you think?

[vladimirfx]

The crucial problem is suspend keyword that changes the method signature at the byte code level by adding Continuation parameter. That parameter either is not supported by classical JVM frameworks or supported and such a method is marked as non-blocking and changes the behavior of context propagation. Even IDE complains about suspend usage in blocking-style projects.

So the question is not how to use Resilience in blocking projects - it is not so hard. The question is about first-class support of blocking style code in Resilience.

Currently, we use such simple utility function for blocking projects:

fun <T> retryOn(
    attempts: Int = Int.MAX_VALUE,
    initialDelay: Duration = 100.milliseconds,
    maxDelay: Duration = 10.seconds,
    timeout: Duration = 60.seconds,
    factor: Double = 2.0,
    errorType: KClass<out Exception> = Exception::class,
    block: () -> T,
): T {
    var currentDelay = initialDelay
    val startedAt = markNow()
    repeat(attempts - 1) { attempt ->
        try {
            return block()
        } catch (ie: InterruptedException) {
            throw ie
        } catch (t: Exception) {
            if (errorType.isAssignableWithCause(t) && startedAt.elapsedNow() < timeout) {
                log.info(t) { "Retry $attempt, elapsed time: ${startedAt.elapsedNow()}" }
            } else {
                throw t
            }
        }
        LockSupport.parkNanos(currentDelay.inWholeNanoseconds)
        currentDelay = (currentDelay.inWholeMilliseconds * factor).toLong().coerceAtMost(maxDelay.inWholeMilliseconds).milliseconds
    }
    return block()
}

Key differences are:

1. No suspend at all (so no Coroutines bytecode level artifacts)
2. Usage of LockSupport.parkNanos for waiting
3. Special treatment of InterruptedException instead of CancellationException

It works but this implementation is much more primitive and inflexible than Resilience.

I don't know how such first-class support may be packaged...

[nomisRev]

Okay, makes perfect sense. 2 & 3 are solve-able, but not 1. Not without dropping suspend support all together from Schedule.

However, I am very interested in collaborating on such a type. But still not entirely sure where it needs to belong, almost feels like a completely new kind-of project, not Arrow related. Such a library could offer more utilities for Loom, such as higher-level builders for parallel, and racing operations? We can make much nicer APIs/DSL in Kotlin, than we can in Java on top of Loom.

I.e. #3411

[vladimirfx]

Okay, I've got your point.

What I can't understand is how reimplementation of Resilience API without suspend fun is related to parallel and racing DSL for Loom? Current Resilience API is fine except suspend keywords. The Implementation needs minimal adjustments.

Thank you for collaboration!

Should I close this discussion?

[nomisRev]

What I can't understand is how reimplementation of Resilience API without suspend fun is related to parallel and racing DSL for Loom?

Not really related, I just wanted to emphasise that if a Loom library is being build it can include more interesting features besides only Schedule.

Should I close this discussion?

Is the issue resolved for you? Is there anything else I can do to help, and support you building this?