Feature/redis module client side caching #662
Conversation
…k on different thread
…ModuleClientSideCaching
update StackExchange.Redis to Version 2.7.4 this enable ClientSideCaching in transactional way Change the way PubSub works ... now possible to receive all Changes in transactional way Checked all Error Messages Bring EnableClientSideCaching to RedisExtensions Bring EnableClientSideCaching to RedisCommandQueue on Create and ReEnable on ConnectionRestored TODO remove old Changes from RedisCommandQueue
…ModuleClientSideCaching
Update to StackExchange.Redis 2.7.4 https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes#274 Enables the complete conversion to ClientSideCaching This is how we get rid of the Custom IsChanged implementation. All critical methods in the RedisCommandQueue and SubscriberExtension implement the NodeContext and IVLRuntime.Current, so that PersistentMessage can also be promoted to VL from Observables that run concurrently. Add HelpPatch for "HowTo External Write to Global Channel.vl" TODO: Implement SerializerEnum(MsgPack, JSon, None) in RedisClient/RedisModule, in Binding "Default, MsgPack, JSon, None" and in Publish and Subscribe. This will be done when VL.MessagePack is ready.
|
Thanks! Will have a look at it today. In the meantime: Redis has two modes for caching, what was the reasoning for choosing the second one (broadcasting)? Can we peek into your thought process here a little bit? Then we were also wondering how the caching modes play together with the transactional reading of the keys. If we only read those for which we got an invalidation message then we might run into inconsistent states, no? |
|
Using the First frame: Fourth frame: Shouldn't it stick to zero? Is this a misconception on my part? Here seems to be a typo: |
|
|
||
| namespace VL.IO.Redis | ||
| { | ||
|
|
||
| public static class RedisExtensions | ||
| { | ||
| internal static ConnectionMultiplexer EnableClientSideCaching(this ConnectionMultiplexer ConnectionMultiplexer, string ClientName, out Spread<long> ClientID, out Spread<bool> IsEnabled) |
There was a problem hiding this comment.
Can we use named tuples here? For example out Spread<(long ClientId, bool IsEnabled)>
| IsEnabled = IsEnabledBuilder.ToSpread(); | ||
| return ConnectionMultiplexer; | ||
| } | ||
|
|
||
| public static Guid getID(this RedisCommandQueue queue) { return queue.id; } | ||
|
|
||
| public static ValueTuple<RedisCommandQueue, TInput> Enqueue<TInput, TOutput> |
There was a problem hiding this comment.
Again, named tuples would help the readability: public static (RedisCommandQueue commandQueue, TInput input) Enqueue...
| cmd.Invoke(tran, input.Item2).ContinueWith(t => new KeyValuePair<Guid, object>(guid, (object)t.Result)), | ||
| keys.HasValue ? keys.Value.Invoke(input.Item2).Select(k => new RedisKey(k)) : Enumerable.Empty<RedisKey>() | ||
| ) | ||
| (tran) => cmd.Invoke(tran, input.Item2).ContinueWith(t => new KeyValuePair<Guid, object>(guid, (object)t.Result)) |
There was a problem hiding this comment.
Here it would then for example read input.commandQueue.Cmds.Enqueue
|
I'll merge this PR now and create separate issues for the things I mentioned here. |
PR Details
Exeption Handeling and ClientSideCaching
Description
[RedisModuleClientSideCaching]
Update to StackExchange.Redis 2.7.4
https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes#274
Enables the complete conversion to ClientSideCaching
This is how we get rid of the Custom IsChanged implementation.
All critical methods in the RedisCommandQueue and SubscriberExtension
implement the NodeContext and IVLRuntime.Current,
so that PersistentMessage can also be promoted to VL from Observables
that run concurrently.
Add HelpPatch for "HowTo External Write to Global Channel.vl"
TODO:
Implement SerializerEnum(MsgPack, JSon, None)
in RedisClient/RedisModule,
in Binding "Default, MsgPack, JSon, None" and
in Publish and Subscribe.
This will be done when VL.MessagePack is ready.
Types of changes