Proper usage of the Redis MessageBus class

[ericrrichards]

I have some questions about the best way to make use of the OrchardCore.Redis.Bus IMessageBus implementation.

I'm trying to use it to pass messages between separate instances in a high-availability cluster. In this particular instance, I'm trying to migrate from an in-memory cache to a distributed cache.

I was trying to use the DocumentManager class to back this up, but I ran into some odd things where it wouldn't commit changes until after a full page reload. Perhaps I'd have better luck with an IVolatileDocumentManager? It's a little tricky trying to understand the internals of some of this stuff, even with digging through the source.

I can inject an instance of the IMessageBus into a service, and subscribe to messages on a particular channel with the .SubscribeAsync() method.

I don't see any way to unsubscribe that handler though. This seems like it would be a bad idea to subscribe to the message bus in a Transient or Scoped service, and even with a Singleton I'm seeing multiple invocations getting raised if I reload an OrchardCore tenant.

[Piedone]

@jtkech perhaps you can help Eric?

[jtkech]

First you need OC.Redis features to have concrete implementations of distributed services.

We don't use too much IMessageBus as we prefer in some places to rely on states than events.

You can take a look at DistributedSignal which makes our ISignal distributed, our default local Signal is already event oriented that's why DistributedSignal uses IMessageBus.

About IVolatileDocumentManager we use it when we don't want to cache the whole data in a distributed cache but in a local memory cache. In that case we only share in the distributed cache a light SomeStateDocument : Document, knowing that any Document has an inner identifier that changes on any update.

So any time the whole data are updated by an instance we also update the shared SomeStateDocument document state, so that any other instance detecting an identifier change will trigger a method to update the data in a local cache, for example data coming from a shared database or any other source. Look at AutorouteEntries which is using this pattern.

Note: Using a shared document state and doing things if its inner identifier changes (comparing to the local one), is another way to implement events, but with a better chance not to lose them which may be important (but not always).

where it wouldn't commit changes until after a full page reload.

Yes, IDocumentManager works alongside IDocumentStore whose default implementation stores in the shared database, so the cached data are updated and then invalidated only if the db transaction complete successfully.

I'm trying to migrate from an in-memory cache to a distributed cache.

If you already have existing code using IMemoryCache (we have one instance per tenant), why not just trying to use IDistributedCache directly, knowing that by default IDistributedCache is just an in memory cache, for example this is what our DefaultDynamicCache and CacheTicketStore are doing.

[Piedone]

Thank you!

[ericrrichards]

Thanks for the pointers @jtkech