1. Yes, if you need ordering, for sure don’t use 4 solution
2. Yes, it happens, but the same things happen in all other points. However, there are mechanisms in spring kafka for handling it. By dafault, it retries the operation several times, you can also apply it: https://docs.spring.io/spring-kafka/reference/kafka/annotation-error-handling.html

1. out of order processing possible
2. offset commits happen before processing of the messages happen, so in case of failure offset is already commited but messages will be never processed

Yes, there was also a similar question from another person in the article comments. By default, Spring Kafka handles offset commits. When we are processing the already received messages in the threap pool it does not have any impact on the offset commits, because it has already been done by the Spring Kafka.

Hi,
I just saw this and had the same question as ROD. Based on the code:
public void listen(Order order) {
LOG.info(“Received: {}”, order);
executorService.submit(() -> service.process(order));
}

We are consuming the message and then submitting it to the thread pool. In this case, we are having the pool size as 30. If all the events are processed in independent threads, then JVM can choose any thread to be process. This can result in a situation where message which was at offset x+10 get processed before the message at offset x.

I am not sure how acknowledgement works in spring kafka but if we are setting the ACK at record level. This behaviour seems likely and if our application goes down at that moment, the kafka should start from latest offset.

Please give more clarity on this.

Definitely no. If you take a look at the scenario 4 once again, you will see that the concurrency at the consumer level is `3`. The thread pool you are asking about (`Executors.newFixedThreadPool(30)`) is processing the already “consumed” messages. Since Spring Kafka is responsible for commiting offsets, it has nothing to do with the offset commitment.

In other words, it would be hard to guarantee delivery of any messages?

Thanks!

Hi!
Thanks! Well, I don’t think that ExecutorService will hinder anything. Why? It just processes messages using thread pool – normal approach. Just a question to your app – if don’t have to process messages sequentially

Just wanted to clarify one thing:-

1. Does using Executor Servcie will hinder the offset mainatinence part, because I don’t want to lose any message maybe due to some downtime or exceptions while processing.

Thanks Again!