[Client-side caching] About the Implementation of CSC

[wp973]

Hi, I would like to ask a question about the implementation of CSC.

Why choose the default mode to implement CSC? Redis documentation describes that the default mode costs some memory on the server side.

  private void initializeClientSideCache() {
    sendCommand(Protocol.Command.CLIENT, "TRACKING", "ON");
    String reply = getStatusCodeReply();
    if (!"OK".equals(reply)) {
      throw new JedisException("Could not enable client tracking. Reply: " + reply);
    }
  }

Thanks~

https://redis.io/docs/latest/develop/reference/client-side-caching/#the-redis-implementation-of-client-side-caching

Redis / Jedis Configuration

Jedis version: 5.2.0 GA

Redis version: > 6.0

Java version: 21

[sazzad16]

We would have to start from somewhere. Right?
It would never be shipped if we were trying to support all the configuration parameters in our first CSC support release.

We welcome PRs to support different CSC configuration parameters.

[wp973]

@sazzad16 Thanks for your reply!

When we use the default mode, maybe we should limit the maximum number of tracking keys to avoid consuming too much server-side memory?

As described in redis.conf:

[sazzad16]

When we use the default mode, maybe we should limit the maximum number of tracking keys to avoid consuming too much server-side memory?

Yes, this is a good idea to follow for the users and maintain at the server side.

[wp973]

hi @sazzad16 , we are doing POC functional verification of CSC(using Jedis). We found that the server-side push of invalidation messages consumes a lot of CPU resources on the server side.

Related issues have been submitted to the redis repository redis/redis#13681.

Please help pay attention to this issue. Thanks!

[wp973]

In the POC, we also encountered the problem of increasing server memory caused by tracking.

tracking mode: default

Related issues: redis/redis#9231.