Using MemoryCacheHandle with RedisCacheBackplane but without RedisCacheHandle

[rebulanyum]

On the documentation it says

/// The cache manager must have at least one cache handle configured with <see cref="CacheHandleConfiguration.IsBackplaneSource"/> set to <c>true</c>.
/// Usually this is the redis cache handle, if configured. It should be the distributed and bottom most cache handle.

I know how to do it with RedisCacheHandle, since it's given as example on Cachemanager's website

var cache = CacheFactory.Build<int>("myCache", settings =>
{
 settings
 .WithSystemRuntimeCacheHandle("inProcessCache")
 .And
 .WithRedisConfiguration("redis", config =>
 {
 config.WithAllowAdmin()
 .WithDatabase(0)
 .WithEndpoint("localhost", 6379);
 })
 .WithMaxRetries(1000)
 .WithRetryTimeout(100)
 .WithRedisBackplane("redis")
 .WithRedisCacheHandle("redis", true);
});

The problem is I don't want to use Redis as cache resource; I just want to make a distributed cache by the power of Redis Pub/Sub mechanism. According to my debugging through the code, by using Redis Backplane feature I'm able to send messages to and receive messages from Redis indeed. So why not use RedisCacheHandle and instead use SystemRuntimeCacheHandle?

So, my expectation was the successfull execution with the following cache configuration

var cache = CacheFactory.Build<int>("myCache", settings =>
{
 settings
 .WithSystemRuntimeCacheHandle("inProcessCache")
 .And
 .WithRedisConfiguration("redis", config =>
 {
 config.WithAllowAdmin()
 .WithDatabase(0)
 .WithEndpoint("localhost", 6379);
 })
 .WithMaxRetries(1000)
 .WithRetryTimeout(100)
 .WithRedisBackplane("redis")
 .WithSystemRuntimeCacheHandle("inProcessCache", true);
});

But it's not working. Can you please show me a solution? What am I doing wrong? Or, eventhough it's written in the documentation as

...Usually this is the redis cache handle...

are there any way to use the cache synchronization feature without RedisCacheHandle?

http://stackoverflow.com/questions/40741986/using-memorycachehandle-with-rediscachebackplane-but-without-rediscachehandle

[MichaConrad]

I guess you with "nor working" you mean that the other caches do not get synced, e.g. if I delete a key from cacheA, it doesn't get deleted from cacheB?
Yes this is currently an expected behavior.

The backplane is intended to work with out of process caches where you have only one state.
With 2 instances of the cache both using system runtime caching, you have two totally disconnected in proc caches.

Normally, if you have a Redis layer and you remove a key from cache instance A, the item would be removed from the Redis layer. The message gets send to other instances of the same cache and would remove the key from any other cache layer but redis (the one marked as backplane source).
This means, we expect that the backplane source is already in sync.

Now what if you have an in-process cache as backplane source. That doesn't work, because both instances will always be out of sync.

Lets look at this example:

 var cacheConfig = ConfigurationBuilder.BuildConfiguration(settings =>
 {
 settings
 .WithSystemRuntimeCacheHandle("inProcessCache")
 .And
 .WithRedisConfiguration("redis", config =>
 {
 config.WithAllowAdmin()
 .WithDatabase(0)
 .WithEndpoint("localhost", 6379);
 })
 .WithMaxRetries(1000)
 .WithRetryTimeout(100)
 .WithRedisBackplane("redis")
 .WithSystemRuntimeCacheHandle("inProcessCache", true);
 });

 var cacheA = new BaseCacheManager<string>(cacheConfig);
 var cacheB = new BaseCacheManager<string>(cacheConfig);
 
 cacheB.Backplane.Removed += (obj, args) =>
 {
 Console.WriteLine(args.Key + " removed from B.");
 };

 cacheA.Add("key", "value");
 
 var result = cacheB.Get("key");
 Console.WriteLine("Result should be null:" + result);

 cacheB.Add("key", "value");
 result = cacheB.Get("key");
 Console.WriteLine("Result should not be null:" + result);

 // triggers backplane remove event
 cacheA.Remove("key");

 // lets give redis some time send messages
 Thread.Sleep(100);
 
 result = cacheB.Get("key");
 Console.WriteLine("Result should be null again but isn't:" + result);

 Console.ReadKey();

If you run this, you can see that the backplane event actually fires but because the only in-proc cache is the backplane source, the key does not get deleted.
That's why at the end, you still get the key returned back to you.

As I said, that is currently the expected behavior.

You could implement custom logic with listening to those events though.
(the events will change slightly in the next version, currently there are a few bugs and inconsistencies).

Also, don't expect that the backplane would transfer cache values over to other instances. That's not going to happen ever. CacheManager only sends key events, not the data because the data is handled by the out of process cache usually.
Meaning, if you have in-proc cache only with backplane, adding an item in cacheA, will NOT copy the item to cacheB! You might get a change event for the key on cacheB though.

I hope that makes sense ;)

[MichaConrad]

lets discuss that on SO as you created a question there, too, which is good /closing it here.

[MichaConrad]

After reading that again on SO I think this is more like a feature request.

But again, I will not implement distributed caching with in memory caches, that's not something which is desirable and is a pretty complex thing. That's what stuff like Redis is meant for and tbh.

The only thing I'd see viable is to remove items from other in memory caches if that's the only layer and the back plane source. That way I can at least invalidate other instances, which kinda makes sense.
The next time you do a get on the other instance, you'd get null (not found) and have to create the data again.
You have to create the cache item again and eventually do expensive operations to do so, but that's the trade off vs using a distributed cache.

[rebulanyum]

That was exactly what I was talking about :). Thank you again for great effort on the product.

[tatarincev]

Hi, is there any estimate for this requirement implementation? We also want to use this kind of cache invalidation without using redistributed Redis cache, because have lot of data serialization issues.

[MichaConrad]

@tatarincev Hi, I have not worked on this yet. I will give it a try soon though, I guess.
What kind of serialization issues due you have?

[tatarincev]

To use Redis cache, all objects should be serializable and this required revision of whole application athitecture. Solution with using redis for cache invalidation will allow to don't touch already exist code and easy make scale out on azure.