v2.9.0

🦅 Eager Refresh now also checks L2

Community member @sfhb24 noticed that during an Eager Refresh the L2 was not being checked.

Now, this is admittedly not a huge thing per se, because of 2 reasons:

• backplane: when using an L1+L2 setup, a backplane is usually also used, and in that case the factory would not run because an update on L2 would be immediately visible to the other nodes
• distributed locker: by using a distributed locker a factory would not run because nodes would coordinate so that only 1 factory runs concurrently, even on multiple nodes

In both these cases, the extra L2 check during an eager refresh would not be necessary.

Having said that, an L1+L2 setup without a backplane or a distributed locker may also be common, and in that case the new L2 check in the eager refresh window can in fact be helpful in reducing the amount of factory executions even more.

Long story short: I just implemented it!

See here for the issue.

🔒 Fix for memory locker + Eager Refresh edge case

If a factory fails when executed in the background during an eager refresh, FusionCache already takes care of everything and correctly releases the potentially acquired locks (memory and/or distributed), and this is good.

But community member @joaopbnogueira noticed a peculiar edge case: if the factory is not one marked with the async keyword AND it throws an exception, the memory lock is not being released properly.

Or, to better say, "was not". Because now this has been fixed.

Thanks João for spotting this.

See here for the issue.

🔒 Fix for distributed locker + skip L1 edge case

Community member @joaopbnogueira also noticed another peculiar scenario, specifically when a MemoryCache write fails (yep, it can happen, true story).

Here's an example of it:

• a custom MemroyCache is being used as the L1
• that instance has been configured with a SizeLimit
• there's a cache miss
• the factory executes successfully
• the new entry does not have a Size specified
• L1 write fails (because with a SizeLimit it's mandatory for every entry to specify a Size)

In this scenario a distributed lock may not have been released.

But fear no more: this does not hapen anymore!

See here for the issue.

🧼 Fix for Clear(false) + Fail-Safe

Community member @joaopbnogueira (damn, he is on a roll!) noticed something else, that somehow went unnoticed until now.

In some cases, after a Clear(false) call, an expired entry saved with Fail-Safe enabled may still be returned by FusionCache.

This too has now been fixed.

See here for the issue.

🔭 Allocation-free tags on the metrics hot path

Community member @GordeySt sent a PR with some really nice optimizations, particularly around reducing resource allocations and CPU consumption when working with metrics.

Now, even with metrics enabled, the hot path is allocation free.

That's great, thanks Gordey!

See here for the PR.

✅ Tests

The test suite just crossed the 1600 mark:

Nice 🙂