Menu
Regard new feature of Kafka aimed for negative acknowledgement and now supported by Spring-Kafka, according to /spring-kafka/docs/2.4.4.RELEASE/
"... Starting with version 2.3, the Acknowledgment interface has two additional methods nack(long sleep) and nack(int index, long sleep). The first one is used with a record listener, the second with a batch listener. Calling the wrong method for your listener type will throw an IllegalStateException.
...
With a record listener, when nack() is called, any pending offsets are committed, the remaing records from the last poll are discarded, and seeks are performed on their partitions so that the failed record and unprocessed records are redelivered on the next poll(). The consumer thread can be paused before redelivery, by setting the sleep argument. This is similar functionality to throwing an exception when the container is configured with a SeekToCurrentErrorHandler. "
Well, if some error happens on consumer side, say fail to save on database, let's say the consumer doesn't acknowledgment.acknowledge(), as far as I understand the message is still on poll and it will be read/consumed again. I guess someone can say that with nack(..., some time) the consumer can sleep giving the chance to read/consume again a bit later and don't face error. If keep listening the topic isn't an issue, my straight question is:
is there any further point on using nack instead of simply not acknowledge?
As far as I can see the message will keep in pool for the time longer than the nack sleep anywhay. So, by the way, if the consumer keeps trying get the message and save the message it will successed assuming the issue is fixed in less than sleep time.
A surrounding point or advantage would be that somehow the producer get notified that nack is used. If so, I could find some worth on it in some specific scenarios. Let's say while using Log Compation (interested only on last message status) or Kafka as a long-term storage service (future releases will provide this I guess - KIP 405)
Regard more general exceptions I tend to follow approaches like configure a SeekToCurrentErrorHandler and throw the exception
805
nack(int index, long sleepMillis) Negatively acknowledge the record at an index in a batch - commit the offset(s) of records before the index and re-seek the partitions so that the record at the index and subsequent records will be redelivered after the sleep time (in milliseconds). default void.
Once Kafka receives an acknowledgement, it changes the offset to the new value and updates it in the Zookeeper. Since offsets are maintained in the Zookeeper, the consumer can read next message correctly even during server outrages. This above flow will repeat until the consumer stops the request.
Kafka Manual Commit - CommitAsync() ExampleBy setting auto. commit. offset=false (tutorial), offsets will only be committed when the application explicitly chooses to do so. This method commits offsets returned on the last poll(Duration) for all the subscribed list of topics and partition.
nack is simply an alternative to using a SeekToCurrentErrorHandler - it was added before we made the SeekToCurrentErrorHandler the default error handler (previously, the default simply logged the error).
The STCEH is more sophisticated in that you can configure the number of retries, configure a recoverer called after retries are exhausted (e.g. DeadLetterPublishingRecoverer).
nack is different to "not acknowledge"; with the latter, if you don't throw an exception, you'll get the next record from the poll (or the next poll if this was the last record); you will not get a redelivery of a not-acked record unless you either use nack or a STCEH and throw an exception.
173
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
