Quittieren innerhalb @ KafkaListener-Methode ohne „verlieren“ -Nachrichten

Question

wir derzeit Nachrichten grundsätzlich mit dem folgenden vereinfachten Mechanismus bestätigen:

@KafkaListener(topics = "someTopic") 
    public void listen(final String message, final Acknowledgment ack) { 
    try { 
     processMessage(message); 
     ack.acknowledge(); 
    } catch (final IOException e) { 
     // do not acknowledge here since we can temporarily not process the message 
    } 

Grundsätzlich, wenn wir vorübergehend die Nachricht nicht verarbeiten können (in Fällen von IOExceptions) wir wollen um es zu einem späteren Zeitpunkt wieder zu erhalten.

Dies funktioniert jedoch nicht, da acknowledge davon ausgeht, dass alle vorherigen Nachrichten innerhalb derselben Partition erfolgreich verarbeitet wurden. Und in unserem IOException-Fall würde die fehlgeschlagene Nachricht übersprungen werden, aber möglicherweise von einer anderen Nachricht mit einem höheren Index auf derselben Partition bestätigt werden.

Wir haben ein paar Ideen, wie wir das beheben können, aber das würde eine unangenehme Lösung bedeuten, um zu vermeiden, direkt in der KafkaListener-Methode zu quittieren. Ist unser Anwendungsfall sehr spezifisch oder ist es nicht eher das "Standard" -Verhalten, das die Kafka-Benutzer im Frühjahr annehmen würden?

Gibt es eine Feder-Kafka-Lösung für diese Art von Problem? Oder haben Sie eine Idee, das "richtig" zu lösen?

Answer 1

So funktioniert Kafka; Sie können versuchen, erneut versuchen, Ihre IOException zu überwinden, bevor Sie mit der nächsten Nachricht fortfahren.

Sie können ein Fehler-Handle für die Veröffentlichung in fehlgeschlagener Nachricht zu einem anderen Thema konfigurieren, um es später wiederzugeben. Oder der Fehlerhandler kann den Container stoppen, um neue Lieferungen zu verhindern.

Wenn der Container neu gestartet wird, wird die Nachricht erneut abgespielt.