]> juplo.de Git - demos/kafka/training/commit
Version des Consumers, die bei Last an Dauer des Poll-Loop scheitert consumer/simple-consumer--max-poll-interval-ms consumer/simple-consumer--max-poll-interval-ms--2026-06-lvm--rebase-vollständig
authorKai Moritz <kai@juplo.de>
Wed, 10 Jun 2026 15:06:06 +0000 (17:06 +0200)
committerKai Moritz <kai.milan.moritz@googlemail.com>
Fri, 12 Jun 2026 18:43:30 +0000 (18:43 +0000)
commit2fd2fef641548bd8a7a04981ea72a2aee541908b
tree0c0879ed13636e91d62558a7a2d7041e729f7d86
parent9d0c92f01c4d393b70655615abae808619530aac
Version des Consumers, die bei Last an Dauer des Poll-Loop scheitert

* Der Consumer legt bei Nachrichten, deren Nachrichten-Inhalt (als Zahl
  betrachtet) modulo 7 glatt aufgeht, eine zufällige Schaffens-Pause von
  0 - 2000 ms ein.
* Außerdem wurde `max.poll.interval.ms` auf 5 s heruntergesetzt und
  `max.poll.records` auf 30 Nachrichten.
* Die Werte wurden über fleißiges ausprobieren so abgestimmt, dass dieser
  Consumer regelmäßig daran scheitert, alle Nachrichten innerhalb der
  vorgegebenen 5000 ms zu verarbeiten, so dass man in den Logs sehr gut
  den asynchron durch den Backrgound-Thread erzeugten Leave-Group Request
  erkennen kann, der bereits erfolgt, _bevor_ der Consumer alle Nachrichten
  verarbeitet hat, erneut `poll()` aufruft und _erst dann_ erfährt, dass
  ihm die Partitionen inzwischen entzogen wurden.
* Um dies noch besser erkennen zu können, wurden außerdem Log-Meldungen vor
  und nach der Schaffens-Pause und - insbesondere - nach der Verarbeitung
  aller erhaltenen Nachrichten eingefügt.
* *BEACHTE:* Der Consumer scheitert nur, wenn sich zuvor ein gewisser
  Rückstau gebildet hat. Solange er in "Echtzeit" eine Nachricht pro Sekunde
  erhält, hat er natürlich keine Probleme.
* Um den Fehler auszulösen, muss der (ansonsten nicht angepasste) Producer
  also mind. 30 Sekunden gelaufen sein, ohne dass ein anderer Consumer die
  Nachrichten konsumiert hat.
src/main/java/de/juplo/kafka/ExampleConsumer.java