Tests with PubSub Messaging never ends when redis crash in 3.2.1

[nicolasb29]

Hi,

Since spring-data-redis 3.2.1, when running tests (with Redis PubSub Messaging), the process no longer ends if the instance of redis crash. In 3.2.0, the test process ends well.

After some research, it seems that a cause could be this commit . When the connection fails:

1. we enter in the function handleSubscriptionException of the class RedisMessageListenerContainer which is calling potentiallyRecover function
2. in potentiallyRecover function, there is a call to recoveryFunction
3. the function recoveryFunction is calling lazyListen
4. in lazyListen function, there is a call to doSubscribe function in a while loop
5. the function doSubscribe is calling the function initialize
6. in this function, there is a RuntimeException and a call is made to function handleSubscriptionException, so we return to step 1 and there is a loop

I tried to make a quick and simple app to be able to test and reproduce the problem:

• clone this project
• start a redis instance with the docker compose (without daemon : docker compose up)
• launch tests
• let the tests run until KafkaApplicationTests4
• when KafkaApplicationTests4 is running, kill the redis process
• Tests are ending but the process never ends

Sample output with version 3.2.0 with a "BUILD SUCCESSFUL in 43s"
320.txt

In 3.2.1, the process never ends because of the loop (in this case I waited 3min) :
321.txt

When I set a FixedBackOff with a maxAttempts value on RedisMessageListenerContainer with setRecoveryBackoff, it ends because he reaches the number of attempts when calling nextBackOff. Is it a workaround or is it the right way to do ?

[mp911de]

With #2782 we reintroduced fail-safety to RedisMessageListenerContainer to continue subscription attempts. The container works the following:

1. If it cannot subscribe initially, subscription (lazyListen) fails.
2. If the initial subscription was a successful and a Redis failure occurs, the container tries to resubscribe until reaching BackOff.maxAttempts.

By default, BackOff.maxAttempts is unlimited.

[nicolasb29]

That's what I understood for the maxAttempts. So the solution is to set a maxAttempts with a FixedBackOff in my test cases when redis crash or stops too soon ? (We are using TestContainers for few years with a GenericContainer of Redis and the shutdownHook stop the Redis, so we have the loop problem. I haven't tried with the official Spring Boot support).

[mp911de]

Yes, using BackOff is the recommended approach. Spring Boot doesn't configure a container bean out of the box. However, when using Spring Session, you get a pre-configured container.

Shutdown hooks aren't reliable in terms of ordering and therefore, you experience quite some issues.

[nicolasb29]

Ok thanks ! I will use a FixedBackOff.