what does retry in KafkaListenerContainerFactory really do?

here is my confusion:

My Kafka Listener Container Factory has a retry template, where I have used the simple retry policy. My Consumer Kafka application basically, listens to a topic and make an API call to third party to send the events that it had listened to. While calling a third party api, I have used web client with RetryBackoffSpec as max attempts set to 3. So technically, my webclient call will make a 3 retry attempts while calling a third party api.

 @Bean public KafkaListenerContainerFactory kafkaListenerContainerFactory() { ConcurrentKafkaListenerContainerFactory factory = new ConcurrentKafkaListenerContainerFactory(); factory.setConsumerFactory(); factory.setErrorHandler(); factory.setRetryTemplate(); return factory; } 

1. In this case will it make sense for me to still have retry template in container factory?
2. What does retry(set in container factory) actually do, is it only making a retry to third party application in my case?
3. Since I am already calling third party api with web client with max attempts set to 3, in this situation will my total retries be 6? 3 from simple retry policy in container factory and 3 from webclient?
4. I also see some blogs saying simple retry policy which is set in container factory also keeps retrying to topics, what kind of use case we have it here?

So far I have simple retry policy (set to 3) and web client retry attempts set to 3. Wondering how it works internally.

1 Answer

It is fully depend what is your listener doing.

This retry on the container level is applied for the whole listener. If you don't not only an HTTP call, then you are not going to have one-to-one replacement for this retry instead of that reactive one.

If you have both, then it is not 6: every single attempt from the container is going to spawn all the attempts for Web Client until control comes back the container for the next attempt. So, together it is going to be 9.

The RetryTempalate support was deprecated in the recent versions. Consider to use respective DefaultErrorHandler or so: