Stackexchange.redis: Support Redis server-assisted client side caching (new in Redis 6)

[giggio]

I saw the comment from @mgravell on https://github.com/StackExchange/StackExchange.Redis/issues/1459#issuecomment-627813702, so I thought it would be nice to have a separate issue dedicated to it.

More info at: https://redis.io/topics/client-side-caching

[bhalval]

Hello Marc and Team,
We are new to Redis Cache and our team is exploring the StackExchange.Redis for our C# and .Net Framework based application. We are mostly able to interface with Redis Cache using the StackExchange.Redis client but one thing we are still struggling with is https://redis.io/topics/client-side-caching. How to do this using StackExchange.Redis client?
OR
It is Redis server management topic and should be handled at server side?
If yes then how to do it on server side?
Hoping for a quick response, thanks in advance.

Regards,
Dheeraj Bhalval

[KamranShahid]

@bhalval
Check https://github.com/StackExchange/StackExchange.Redis/issues/1459
Client caching is a very new feature so obviously take time.

[mgravell]

I can confirm this isn't something we've had chance to look into yet, but it is on our roadmap - and as it happens, I was rewriting our own internal pre-redis-6 implementation of this just last week (for Stack Overflow). Properly designing, implementing, testing, documenting etc this is going to take a little while.

[bhalval]

@mgravell and @KamranShahid
Thanks a lot for confirming as I was fretting over it for past week. So as an alternative, what would be your suggestion for client side caching?

[mgravell]

I do not have a specific suggestion there for now. As I say: it is on our
list to look at. For other things for now: you'd have to look. We have some
internal code we've wanted to open up for a while, but it needs time and
effort.

On Sun, 14 Jun 2020, 17:32 bhalval, [e-mail] wrote:

@mgravell https://github.com/mgravell and @KamranShahid
https://github.com/KamranShahid
Thanks a lot for confirming as I was fretting over it for past week. So as
an alternative, what would be your suggestion for client side caching?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/1461#issuecomment-643790243,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEHMDK47FK67SMHKCI5Y3RWT3Q5ANCNFSM4NABAEAA
.

[bhalval]

Thank you @mgravell.

[haiduc32]

Are there any updates?
Has anyone found a way to get it working? Any workarounds?

I tried to Get Client Id (by guessing mostly) on the Subscription connection and set tracking with redirect, but it never receives invalidate messages (or maybe fails silently).
I also tried ServiceStack.Redis, but it just throws some errors when I try to use it with tracking.

[Greatsamps]

Would also be interested in this

[BK-Soft]

@mgravell why not open the internal code for this feature? (it seems a good feature that could boost Redis )

[mgravell]

Because everything requires time and effort, and the more code we add, the
more code we need to support. The library is massively downloaded, and we
get zero paid hours to support it. Math.

On Fri, 22 Jan 2021, 21:50 BRAHIM Kamel, [e-mail] wrote:

@mgravell https://github.com/mgravell why not open the internal code
for this feature? (it seems a good feature that could boost Redis )

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/1461#issuecomment-765704701,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEHMHYSSQQO47DZXXN2FLS3HXLTANCNFSM4NABAEAA
.

[BK-Soft]

@mgravell all your arguments are understandable and you're doing a great job, but opening the code to the community (even with a fork and marking it as experimental) could reduce the time effort from maybe days/months to a few hours. right?

[KamranShahid]

@mgravell all your arguments are understandable and you're doing a great job, but opening the code to the community (even with a fork and marking it as experimental) could reduce the time effort from maybe days/months to a few hours. right?

isn't code available here? i think you can download it can play with whatever you can try

[BK-Soft]

@KamranShahid it's an internal code as mentioned by @mgravell there is no way to play with it

[KamranShahid]

@KamranShahid it's an internal code as mentioned by @mgravell there is no way to play with it

Ok. is it also obfuscated :)

[br3nt]

It seems we could use var response = db.Execute("CLIENT", "TRACKING", "ON"); to enable client tracking, but how do we then "listen" for the corresponding invalidation messages?

[br3nt]

I have managed to enable client tracking manually using Execute but I have run into a road block.

StackExchange.Redis seems to create two connections: one for the database, and one for the subscriber.

So, var invalidatorClientId = invalidatorDb.Execute("CLIENT", "ID"); gets the client id for the database connection rather than the subscriber connection.

This means that clientDb1.ExecuteAsync("CLIENT", "TRACKING", "ON", "REDIRECT", (string)invalidatorClientId) is setting up redirection to the incorrect connection.

Does anyone know of a way to get the client id of the subscriber connection??

Just for reference, this is my current code... Im setting up client tracking with redirection because I assume RESP2 is used by default by StackExchange.Redis.

// connection 1 - used to receive invalidation messages
var invalidator = ConnectionMultiplexer.Connect("localhost:6379", Console.Out);
var invalidatorDb = invalidator.GetDatabase();
var invalidatorClientId = invalidatorDb.Execute("CLIENT", "ID");

// connection 2 - used to test client tracking
var client1 = ConnectionMultiplexer.Connect("localhost:6379", Console.Out);
var clientDb1 = client1.GetDatabase();
var clientId1 = clientDb1.Execute("CLIENT", "ID");

// connection 3 - used to test client tracking
var client2 = ConnectionMultiplexer.Connect("localhost:6379", Console.Out);
var clientDb2 = client1.GetDatabase();
var clientId2 = clientDb1.Execute("CLIENT", "ID");

// subsribe to invalidation messages
var subscriber = invalidator.GetSubscriber();
subscriber.Subscribe("__redis__:invalidate").OnMessage(message =>
{
    Console.WriteLine($"__redis__:invalidate: {message}");
});

// enable client tracking
Console.Write("clientDb1 tracking: ");
Console.WriteLine(await clientDb1.ExecuteAsync("CLIENT", "TRACKING", "ON", "REDIRECT", (string)invalidatorClientId));

Console.Write("clientDb2 tracking: ");
Console.WriteLine(await clientDb2.ExecuteAsync("CLIENT", "TRACKING", "ON", "REDIRECT", (string)invalidatorClientId));

// register keys to enable tracking
await clientDb1.StringSetAsync("a", "Hi");
await clientDb2.StringSetAsync("a", "Hey");

// test client tracking by updating of the keys
// it is expected that messages will be published by the server to the `__redis__:invalidate` channel
// the subscriber handler above, should print the invalidation message to the console
int i = 0;
while (!stoppingToken.IsCancellationRequested)
{
    clientDb1.StringSet("a", $"A{i++}");
    Console.WriteLine(clientDb2.StringGet("a"));

    //_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
    await Task.Delay(1000, stoppingToken);
}

[mgravell]

As discussed in our Stack Overflow conversation here, this will require library changes, to (reliably) get the CLIENT ID as part of the initial connection handshake. They're not huge or risky changes, note.