v0.24.0

⚠️ Update Notes

If you are updating from a previous version, please read here.

↩️ Brand new Auto-Recovery (docs)

The old Backplane Auto-Recovery is now, simply, Auto-Recovery!

It shines above the other features as a way to automatically handle and resolve transient errors with timed retries and other techniques, to do the best it can to avoid leaving your cache in a dire situation, no matter what.

Lately I proceeded with an almost complete rewrite of the internals of the entire distributed part, meaning both the distributed cache and the backplane, and in particular the auto-recovery feature to make it all even better..

This is the culmination of many months of research, experimentation, development, testing, benchmarking and in general a lot of work.

The new Auto-Recovery now supports both the distributed cache and the backplane, either individually or together.

Now it is also active, meaning it handles retries automatically instead of waiting for an external signal to "wake up".

Some of these improvements include:

• continuous background processing (more robust)
• queue automatic cleanup
• active detection and processing of re-connection
• the distributed cache and the backplane now work together even more (and better) than before, with granular control of re-sync operations needed
• better handling of connection/subscription errors
• better logging

Every edge case I thought of and all the others reported to me by the community are handled, all automatically.

You can read some of them at the dedicated docs page.

Please note that all the existing options named BackplaneAutoRecoveryXyz are now named simply AutoRecoveryXyz: this is not a breaking change though, since the old ones are still present but marked with the useful [Obsolete] attribute. Simply update to the latest version, recompile, look for some warnings and do the appropriate changes, if any.

🖥️ Simulator (docs)

In general it is quite complicated to understand what is going on in a distributed system.

When using FusionCache with the distributed cache and the backplane, a lot of stuff is going on at any given time: add to that intermittent transient errors and, even if we can be confident auto-recovery will handle it all automatically, clearly seeing the whole picture can become a daunting task.

It would be very useful to have something that let us clearly see it all in action, something that would let us configure different components, tweak some options, enable this, disable that and let us simulate a realistic workload to see the results.

Luckily there is, and is called Simulator.

📢 Better Backplane (docs)

This version introduces a better way to handle incoming backplane messages: long story short, it will now take less time for a change to be propagated to all the other nodes, and to be reflected into their local memory cache (only if necessary, to save resources).

📞 Eviction event now pass the cache value (docs)

Thanks to a request by community member @giulianob the Eviction event in the memory cache has been made more powerful, and is now passing the cache value being evicted.

This can be useful for example to dispose a value being evicted from the cache, or more.

See here for more.

💥 Custom Exceptions

FusionCache now has 3 new custom exception types that are used to generalize errors of 3 main types: distributed cache errors, serialization errors and backplane errors.

In this way it will be easier to catch exception "groups" in our code instead of special-case it to work with Redis, CosmosDB, etc.

In case the old behaviour is needed for some reason, we can simply set the ReThrowOriginalExceptions options to true.

🕑 Better timestamping

Timestamps are now more precise, and are used more inside the various heuristics used to handle conflicts and more.

⚙️ Added ReThrowBackplaneExceptions option

It is now possible to more granularly specify if we want to re-throw exceptions happened in the backplane code.

To allow this though we need to disable background execution of the backplane (via the AllowBackgroundBackplaneOperations option), otherwise it would be physically impossible to re-throw them.

📜 Better Logging

Logging messages are now even better, with more useful information.

One that shines in particular and that is fundamental in debugging distributed issues is the inclusion of the InstanceId on top of the CacheName: with this we can better identify who sent messages to who without any doubt.

🔴 Add support for ConnectionMultiplexerFactory in RedisBackplane

It is now possible to directly pass an instance of IConnectionMultiplexer to waste less resources, thanks to a PR by the community user @JeffreyM .

Thanks Jeffrey!

🐞 NullFusionCache now correctly handles CreateEntryOptions

Thanks to a bug report by community member @kelko , a small issue has been fixed with the standard NullFusionCache implementation.

See here for more.

🐵 New base AbstractChaosComponent

Historically all the chaos-related components (eg: ChaosBackplane, ChaosDistributedCache, etc) all re-implement the same core properties and methods to control throws probability, random delays and so on.

Now that these components exist for some time and they are working well, they needed a little refactoring.

So a new AbstractChaosComponent has been created acting as a base class for all chaos-related components, so that they now all inherit from it to result in less code and better evolvability.

See here for more.

🐵 Added support for cancellation in chaos components

Chaos components now supports cancellation via the standard use of CancellationTokens.

✅ Better Tests

The tests have been reorganized, better splitted into different files, they now have a unique abstract base class with some common useful stuff and most of them now have logging enabled, just in case.

📕 Docs

Finally I've updated a lot of the existing docs and added some new ones, like for the brand new AutoRecovery feature, for the Simulator and more.