How to add client cache invalidation listener?

[max-grigoriev]

Right now CacheFrontend interface doesn't have addInvalidationListener method. It only exists ClientSideCaching implementation. And there are two static methods in this implementation to create the client side cache:

public static <K, V> CacheFrontend<K, V> enable(CacheAccessor<K, V> cacheAccessor, 
    StatefulRedisConnection<K, V> connection, 
    TrackingArgs tracking) {...}

public static <K, V> CacheFrontend<K, V> create(CacheAccessor<K, V> cacheAccessor, 
    StatefulRedisConnection<K, V> connection) {...}

but they return the interface. So the only way is to cast to implementation which is wrong as the method can return any implementation.

[mp911de]

ClientSideCaching is a tiny facade making use of CacheAccessor and StatefulRedisConnection. The internally used invalidation listeners aren't really intended for outside usage because they are invoked on I/O threads and the context is pretty much leading to the desire to invoke further Redis activity or blocking actions.

In general, we kept the Client-side support pretty minimal to learn where all this is going. Having a few real-world use-cases can help to understand the need for additional functionality so that we can improve the API.

[YaroslavSaakyan]

Here is a real use-case. Our service communicates with it's clients through the websocket connections. We use Redis to keep some data, associated with the websocket connections. Once the entry in Redis is expired, we want to get a message and perform some logic (close a websocket connection, associated with the expired entry, e.t.c.). It looks like ClientSideCaching is what we need to implement this logic, so it would be nice to be able to add custom invalidation listeners.

[mp911de]

I'm not sure that ClientSideCaching fits. What you're looking for are key-space notifications and not Server-assisted tracking of keys that were touched by the client, no?

In any case, ClientSideCaching needs more design.