Performance comparison of RetryTemplate vs ErrorHandler - spring-kafka

Question

I have two ways of recovering from KafkaListener errors with using
RetryTemplate in the KafkaListener method:
#KafkaListener(topics: "topic1")
public void handle(command) {
retryTemplate.execute(ctx -> {
processCommand(command);
});
// Retries exhausted, execute the recoverer logic
recover(command);
}
Set ErrorHandler to MessageListenerContainer via ContainerCustomizer:
#Component
public class ContainerCustomizer {
public ContainerCustomizer(CustomConcurrentContainerListenerFactory factory) {
factory.setContainerCustomizer(container -> {
container.setErrorHandler(new SeekToCurrentErrorHandler((ConsumerRecord<?, ?> record, Exception e) -> {
//logic for recoverer after retries exhausted
recover(convertRecord(record));
}, new ExponentialBackOffWithMaxRetries(2)));
});
}
}
When it comes to performance and blocking the consumer thread, how these two options compare? Is it true to say that with RetryTemplate.execute, retries are handled in a separate thread while with containerListener.setErrorHandler it blocks the main consumer's thread?

Answer 1

Both will block the consumer thread - otherwise you'd continue processing records and Kafka's ordering guarantees would be lost.
Also, both approaches are deprecated in favor of DefaultErrorHandler, which is an evolution of SeekToCurrentErrorHandler.
The difference between the two is, with Spring Retry, all invocations will be retried in memory, so you should make sure the aggregate backoff won't exceed the max.poll.interval.ms or the broker will think your server is dead and will perform a rebalance.
SeekToCurrentErrorHandler, as well as DefaultErrorHandler, will perform a new seek to the broker for each retry, so you just need to make sure the biggest delay plus execution time does not exceed max.poll.interval.ms.
If you need non-blocking retries, take a look at the non-blocking retries feature.