Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Conflict between backplane behavior and documentation #313

Open
shahaf-SG opened this issue Oct 5, 2024 · 1 comment
Open

[BUG] Conflict between backplane behavior and documentation #313

shahaf-SG opened this issue Oct 5, 2024 · 1 comment

Comments

@shahaf-SG
Copy link

shahaf-SG commented Oct 5, 2024

The backplane documentation states that the lazy approach is being used (each client removes their local version of the data).
However, when a set notification is received, the passive approach is used (each client updates their local version from the distributed cache).

@jodydonetti
Copy link
Collaborator

Hi @shahaf-SG , sorry for the delay but I just came back from (very late) summer vacations 😅

Thanks for spotting it, you are in fact (partially) correct.
But why "partially"? Let me explain.

When I wrote the first implementatio of the backplane LAZY was in fact how it worked.
Then Auto-Recovery entered the scene, and I decided to tweak the internal behaviour to work better in all possible cases.

But now you may say something like "the PASSIVE mode had some negative aspects, aren't they still valid?" and to that the answer is that yes, they still are, BUT what I'm doing right now is not the PASSIVE mode I described there, which would mean going to get the value for the notified cache key on all the other nodes. What FusionCache does now is kind of a middle ground between LAZY and PASSIVE, you can call it LAZY++ (or PASSIVE-- 😬), because I go get the latest version of the data for that cache key BUT only if the value is already present in the local memory cache (L1).

Basically what I achieved is kind of the best of both worlds: FusionCache immediately updates the data in L1 ONLY if it is already there on that node, so that if cache key "foo" is in the memory cache of only 2 of 10 nodes, only those 2 nodes will get the data. This avoids the problems of the PASSIVE approach, at least as described in the (current) docs.

Anyway you are right in that the docs should be updated, thanks for pointing that out!

Will do as soon as possible, will update when I've done that.

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants