Is "Expire" broken?

[andriibratanin]

Hey, @jodydonetti. First of all, thank you for all the effort and care you give to the community! Seems like I need your advice.

I am trying to fugure out how to use FusionCache with Redis as a L2 for "cold start". While experimenting with settings I've found that with FailSafe enabled calling Expire immediatelly removes the value from Redis, thus behaving just like Remove. And this is where I get confused...

Accorting to docs the Expire "method may be is useful in case we want to threat something as remove, but with the ability to say "better than nothing" in the future, in case of problems (thanks to fail-safe)", but at the same time heredocs in the code for Expire tell us "In the distributed cache (if any), the entry will always be effectively removed".

Thus, immediate deletion of the value from L2 cache makes the use of it as "stale" (in case if its factory fails) impossibe.

Are we sure there is no bug in Expire logic?

Thank you!

[jodydonetti]

Hi @andriibratanin

Hey, @jodydonetti. First of all, thank you for all the effort and care you give to the community!

Thanks, really appreciate it!

I am trying to fugure out how to use FusionCache with Redis as a L2 for "cold start". While experimenting with settings I've found that with FailSafe enabled calling Expire immediatelly removes the value from Redis, thus behaving just like Remove. And this is where I get confused...

Accorting to docs the Expire "method may be is useful in case we want to threat something as remove, but with the ability to say "better than nothing" in the future, in case of problems (thanks to fail-safe)", but at the same time heredocs in the code for Expire tell us "In the distributed cache (if any), the entry will always be effectively removed".

Thus, immediate deletion of the value from L2 cache makes the use of it as "stale" (in case if its factory fails) impossibe.

I see what you mean, let me explain why it is the way it is (and let me know what you think about it).

First thing: you are right about the docs, I should make them more clear. Added this to my backlog, thanks!

Second: distributed caches in general (and IDistributedCache in particular) don't support partial updates (think like PATCH in the HTTP world), so you can't ask to "update only the stale flag for this entry" on L2, but you can only do full SET operations.

But to do this, FusionCache needs all the info about the entry, and the core problem is that you can call Expire() for an entry on a node where that entry itself is not in L1, or where the entry is in L1 but it's stale. Therefore doing the full SET on L2 would be either impossible (in case it's missing in L1) or it would require a full GET on L2 + a full SET after that.

So the idea is that, whn doing an Expire() with fail-safe:

• entry is removed in L2 to avoid the issues above
• for all the nodes that already have that entry in L1, the entry will be marked as stale locally (allowing a future fail-safe use as a fallback value)
• for all the nodes that don't have that entry in L1, nothing was there already anyway so fo fail-safe fallback for them

I think this is the most that can be done without overloading L2 with extra calls or risking out-of-sync updates.

Are we sure there is no bug in Expire logic?

No, I wouldn't say it's bugged, I'd say it tries to do the best in ca with the available underlying L2 features.

But I'd like to know from you, now with more insights into why it works the way it works: what do you think?

[andriibratanin]

It wasn't obvious for me (and BTW, is it in docs?) that the value is still in L1 for the fail-safe functionality even if it was removed from L2. Now, with all arguments you've mentioned, everything sounds reasonable.

In my case:

• I am happy that fail-safe and "cold start" is working like a charm without Expire.
• Probably I expected "too much" for the very edge-case (fail-safe on "cold start" after Expire) :)

Thank you!

PS: A side note in regards docs - here is a gotcha I'd like to be mentioned explicitly on FailSafe page:
"We can SET with fail-safe and later GET without using it, but we cannot GET with fail-safe if the previous SET call didn't have it enabled"

[jodydonetti]

PS: A side note in regards docs - here is a gotcha I'd like to be mentioned explicitly on FailSafe page: "We can SET with fail-safe and later GET without using it, but we cannot GET with fail-safe if the previous SET call didn't have it enabled"

This is the part that should highlight what you are saying:

Maybe I should change the wording? What do you think?

[jodydonetti]

PS: the GitHub css styles for bold text is such that (at least on Windows) it does not make it so evident... maybe i should use UPPERCASE WORDS more because of this.

(btw apart from this minor thing I just love the GitHub css styles, really a sweet spot of clarity, style and readability)

[andriibratanin]

Maybe I should change the wording? What do you think?

For me, as a person who have read ALL the docs, it is clear.

I just love the GitHub css styles, really a sweet spot of clarity, style and readability

+1 "soulmate" achievement unlocked ;)

Thank you for hearing my voice.

[jodydonetti]

For me, as a person who have read ALL the docs, it is clear.

ALL? Woah 😮

Thank you for hearing my voice.

Thank you for sharing it!