smallrye-mutiny: Provide the possibility to invalidate a cached Uni

Done in #312, superseded by #313

@heubeck I pushed an early sketch / draft in #313

It provides cacheUntil(BooleanSupplier) and cacheFor(Duration).

Note that in this design invalidation is checked on new subscriptions, it looks quite sane to reason about IMHO. If we start also checking when and item or failure is ready to be propagated downstream then we may have starvation / infinite loops, especially in the cacheUntil case if the condition changes on the same thread.

@heubeck I’m still willing to explore and see if we can come up with a good solution here. Right now cache() provides us with memoization. Supporting invalidation (like a Clojure library does) is a good investigation area.

@jponge I have not found a use for it yet, but remember that so far we have not progressed much beyond just writing simple test cases for HR.

I’ve kept your PR open as draft for reference @heubeck

I’ve been exploring some designs with synchronized blocks but it’s not great (but apparently correct). I’m going to have a look at drain loops and see if we can make it work this way.

Thinking out loud. On the other hand I’m wondering if we are not trying to ask too much for what Uni can do. A Uni represents an operation, and caching a result is perhaps something that should be done as part of an application business logic rather than in Uni itself. Invalidation can quickly become complex, and there are good libraries for that (e.g., https://github.com/ben-manes/caffeine).

Looking into it, there is indeed an opportunity to explore another design. It’s a more complex state machine if re-subscription happens. It’s on my radar.

I like the idea of having a cache group.

asLong should be atMost to be homogeneous and receive a Duration.

We could still keep the current cache method which would redirect on cache().indefinitely().

Le sam. 1 août 2020 à 00:21, Florian Heubeck notifications@github.com a écrit :

@jponge https://github.com/jponge suggested

Interesting, would you have a small snippet that would benefit from the feature?

Also how about cacheWhile(Predicate) as an alternative name?

wouldn’t that pollute the Uni API? If breaking changes are accepted I could try to refactor to a cache config similar you provide for most other API branches (please help me name it):

// current behaviour would become: Uni.cache().indefinitely() // Positive cache validity checking: Uni<T>.cache().asLong(Predicate<T>) // The other was around: Uni<T>.cache().until(Predicate<T>)

If you do not want to enhance the caching stuff further, than I’m happy with Uni.cacheWhile(Predicate) side by side with Uni.cache().

Thank you for reading my thoughts, looking forward to implement a proposal.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/smallrye/smallrye-mutiny/issues/231#issuecomment-667410372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCG7JDGXHJB2SLW5AREITR6M7VBANCNFSM4PG5E2SQ .

@heubeck we’re more or less all in vacations or going to vacations, so don’t be surprised to not hear back anything for the next 2-3 weeks.

Meanwhile if you have time and fancy looking at what’s under the cover, feel-free to hack and possibly open a pull-request 😉

Already thought about doing this - hope to free some time.

Have a good time and thank you @jponge .

@heubeck we’re more or less all in vacations or going to vacations, so don’t be surprised to not hear back anything for the next 2-3 weeks.

Meanwhile if you have time and fancy looking at what’s under the cover, feel-free to hack and possibly open a pull-request 😉

Interesting