Presently, one has to make a very bad choice when using NCache in .Net Core 3.1 as the backing object for IDistributedCache. Either set NCacheConfiguration.ExceptionsEnabled = false and have your web application lose all ability to detect, report, and handle when the cache has problems, XOR set that to true and risk the web application completely failing to start if there's any sort of problem with the cache during initialization.
Right now, any number of race conditions or temporary situations can cause the entire application to fail after a reboot or an AppDomain recycle. (NCache is still starting up, network cable unplugged, NCache on a different machine that is still rebooting, etc.)
NCacheDistributedCache calls CheckAndInitializeCache() at every Get/Set, so there's no loss.
Thanks for your inputs, I have discussed this with our engineering team and they have concluded this to be a valid feature request. Engineering has planned to include this in our next public release.
Presently, one has to make a very bad choice when using NCache in .Net Core 3.1 as the backing object for IDistributedCache. Either set NCacheConfiguration.ExceptionsEnabled = false and have your web application lose all ability to detect, report, and handle when the cache has problems, XOR set that to true and risk the web application completely failing to start if there's any sort of problem with the cache during initialization.
Right now, any number of race conditions or temporary situations can cause the entire application to fail after a reboot or an AppDomain recycle. (NCache is still starting up, network cable unplugged, NCache on a different machine that is still rebooting, etc.)
NCacheDistributedCache calls CheckAndInitializeCache() at every Get/Set, so there's no loss.