Add an event to RedisContainer when subscription is ready [DATAREDIS-1047]

[spring-projects-issues]

Piotr opened DATAREDIS-1047 and commented

Currently addMessageListener is asynchronous method and there is no way to determine if a subscription is ready (it uses lazy loading). In my scenario I need to know when a service is ready to receive messages from Redis as it needs to send initial state to connected clients.

The feature would be also useful for scenarios when subscriptions are added at runtime rather than at startup.

 

The similar problem was reported here: https://stackoverflow.com/questions/32297321/spring-data-redis-how-do-i-know-that-messagelistener-is-ready

---

No further details from DATAREDIS-1047

[spring-projects-issues]

Mark Paluch commented

We could likely provide such a feature by using Redis subscription notifications. It would make sense to allow MessageListener objects to implement another interface that notify the listener when a subscription is acknowledged by Redis. Following this idea, we could also introduce a possibility to await subscriptions when the container is started via RedisMessageListenerContainer.start.

Care to elaborate a bit on your use-case? Are you just interested in awaiting the container startup or do you want to await if a particular subscription is activated?

[spring-projects-issues]

Piotr commented

This is our use case:

1. A client connects to a server. The server subscribes to Redis channel which is specific to such client. The redis channel contain some data (specifically notifications) which the connected client wants to receive.
2. The server sends a list of current notifications to the connected client as "initial state". This contains a list of all notifications which haven't sent yet to the client. We store them in a database.
3. Whenever a new notification is published to Redis channel it's sent by a server to the client.

 

The problem here is that there is a race condition  if the events occur in the following order:

1. The client connects to the server.
2. Server subscribes to Redis.
3. Server sends an initial state (a list of notifications)
4. The new notification is sent to Redis but server is not yet fully subscribed to Redis so the client will never receive it.
5. Redis subscription is ready. From now all notifications sent to Redis will be send to client via server.

 

In lettuce there is way to react when the subscription is ready. In our case we could use this event to send "initial state" to client. In other words, we need to know when the redis subscription is ready so we can send initial state

[spring-projects-issues]

Mark Paluch commented

Thanks a lot for the background details. So both enhancements, awaiting the container startup (delay application context startup) as well as awaiting that a single subscription gets active make sense. We would introduce two changes:

1. A new interface that can be implemented by MessageListener objects to call them back on subscription/unsubscription. Individual message listeners can then implement code to allow synchronization (e.g. CountDownLatch).
2. The container gets a configuration option to await subscriptions. The effect is that the start() method would await until all subscriptions are active when starting the container. Furthermore, calls to addListener and removeListener would await subscription/unsubscription. We need to pay special attention if we have multiple subscriptions to a particular pattern/channel

[spring-projects-issues]

Piotr commented

Great, it makes sense. Any of these changes would resolve our problem

[mp911de]

Depends on #1697

[mp911de]

Depends on #2054

[mp911de]

This will be fixed via #964.