Kai Moritz [Sun, 24 Jul 2022 16:39:05 +0000 (18:39 +0200)]
Das Speichern der Daten und Offsets erfolgt nicht mehr nach jedem `poll()`
* Statdessen kann eine `Duration` konfiguriert werden.
* Ähnlich wie in der Client-Library von Kafka, wird ein Zeitstempel für
den letzten Commit gespeichert und die Daten werden immer dann
gespeichert, wenn dieser weiter als das eingestellte
`consumer.commit-interval` in der Vergangenheit liegt.
Kai Moritz [Sun, 24 Jul 2022 16:22:00 +0000 (18:22 +0200)]
Wenn kein gespeicherter Offset vorliegt, auto.offset.reset von Kafka nutzen
* Es wird jetzt nur noch dann ein expliziter Seek durchgeführt, wenn eine
gespeicherte Offset-Position gefunden wurde.
* Andernfalls wird der von Kafka initialisierte Ausgansgs-Offset verwendet.
* Welchen Offset Kafka vorgibt, hängt von `auto.offset.rest` ab!
Kai Moritz [Sun, 24 Jul 2022 14:15:23 +0000 (16:15 +0200)]
Ausgabe der verarbeiteten Nachrichten im Revoke-Callback entfernt
* Es musste allein für diese Ausgabe eine Map mit den zuletzt eingelesenen
Offset-Positionen gepflegt werden.
* Das ist zu viel Overhead, für die Randmeldung im Log.
Kai Moritz [Sun, 24 Jul 2022 14:12:04 +0000 (16:12 +0200)]
Fehler in Logging-Ausgabe korrigiert
* Der über den Merge hinzugefügt Test hat einen Fehler aufgedeckt.
* In onPartitionsRevoked() wurde bei der Berechnung der verarbeiteten
Nachrichten für die Log-Ausgabe ein Nullzeiger dereferenziert.
* Ursache dafür war, dass die Map `offsets` in der Version, die die Offsets
speichert gar nicht mehr gepflegt wurde.
Kai Moritz [Sun, 24 Jul 2022 13:35:14 +0000 (15:35 +0200)]
Merge der Refaktorisierung des EndlessConsumer (Branch 'stored-state')
* Die `commtSync()`-Aufrufe machen beim Speichern der Offsets außerhalb
von Kafka keinen Sinn mehr.
* Der Testfall musste an die extern gespeicherten Offsets angepasst
werden: Die gesehenen Offsets müssen aus der MongoDB gelesen werden,
anstatt über einen separaten Consumer aus Kafka.
* Der mit dem Merge hinzugefügte Test schlägt fehl, da er einen Fehler
aufdeckt (NPE bei einer Log-Ausgabe zur Offset-Verarbeitung).
Kai Moritz [Sun, 24 Jul 2022 10:34:53 +0000 (12:34 +0200)]
Merge der Refaktorisierung des EndlessConsumer (Branch 'deserialization')
* Um die Implementierung besser testen zu können, wurde die Anwendung
in dem Branch 'deserialization' refaktorisiert.
* Diese Refaktorisierung werden hier zusammen mit den eingeführten
Tests gemerged.
* Der so verfügbar gemachte Test wurde so angepasst, dass er das Speichern
des Zustands in einer MongoDB berücksichtigt.
Kai Moritz [Sat, 23 Jul 2022 11:26:29 +0000 (13:26 +0200)]
Compose-Konfiguration unabhängig von Default-Konfiguration gemacht
* Damit Instanzen parallel über die IDE (mit voreingestelltem Default-Port)
und Compose gestartet werden können, wurden den einzelnen Komponenten
(Producer, Consumer etc.) jeweils unterschiedliche explizite
Default-Ports zugewiesen.
* Dies führt leicht zu fehlern, in den Compose-Setups, da dort i.d.R.
Port-Mappings für die gestarteten Instanzen definiert werden.
* Daher werden die Compose-Setups jetzt so umgestellt, dass sie den
einkompilierten Default-Port der Komponenten explizit mit dem Port `8080`
überschreiben, so dass alle Komponenten _innerhalb_ von Compose
einheitlich (und so wie bei Spring-Boot standard) über `8080` ansprechbar
sind.
Kai Moritz [Fri, 22 Jul 2022 18:04:07 +0000 (20:04 +0200)]
Upgrade von Spring Boot und den Confluent-Kafka-Images
* Upgrade der Kafk-Images von Confluent 7.0.2 auf 7.1.3
** Unterstützt Kafka 3.1.x (siehe https://docs.confluent.io/platform/current/installation/versions-interoperability.html[Versions-Matrix])
* Upgrade für Spring Boot von 2.6.5 auf 2.7.2
** Enthält Kafka: 3.1.1
** Enthält Spring Kafka: 2.8.8
Kai Moritz [Mon, 18 Apr 2022 10:41:47 +0000 (12:41 +0200)]
Tests: Refaktorisiert - Durcheinander bei Assertions aufgeräumt
* Zuvor wurden die Assertions von JUnit Jupiter und AssertJ durcheinander
gewürfelt verwendet.
* Jetzt werden stringent nur noch die Assertions von AssertJ verwendet.
Kai Moritz [Mon, 11 Apr 2022 07:41:40 +0000 (09:41 +0200)]
Tests: Der Test wartet, bis die Offsets regulär committed wurden
* Zuvor wurde der Offset-Commit erzwungen, indem der EndlessConsumer
über den Aufruf von `stop()` beendet wurde.
* Jetzt wird die Überprüfung der Erwartungen über awaitility aufgeschoben,
bis die Erwartungen beobachtet werden können - oder eine Zeitschranke
gerissen wird.
Kai Moritz [Sun, 10 Apr 2022 20:50:44 +0000 (22:50 +0200)]
Tests: Der EndlessConsumer wird jetzt doch asynchron ausgeführt
* Der Test-Code wird verständlicher, wenn der Consumer asynchron läuft
* Für die Überprüfung der Erwartungen wird dann awaitility benötigt
** Da der Consumer in einem separaten Thread läuft, muss auf diesen
gezielt gewartet werden
** Dafür wird es deutlicher/verständlicher, auf welche der auch aus dem
regulären Betrieb des EndlessConsumer bekannten Zustandsänderungen
der Test wartet
* Da die Offsets für die Controlle (ggf.) abgefragt werden, während der
EndlessConsumer noch läuft, wird ein separater KafkaConsumer benötigt,
um die Offsets abzurufen.
BEACHTE: Um die Änderungen in dem Offsets-Topic zu greifen zu bekommen,
muss dieser KafkaConsumer für jede Abfrage ein `assign()` durchführen,
damit er gezwungen ist, die Offsets neu vom Broker zu erfragen.
Kai Moritz [Sat, 9 Apr 2022 11:40:47 +0000 (13:40 +0200)]
Refaktorisierung für Tests - Record-Handler als Bean konfigurierbar
* Ein Handler für die Verarbeitung der einzelnen ConsumerRecord's kann
jetzt ein `java.util.function.Consumer` als Bean definiert werden
* Die Nachricht wird erst nach dem Aufruf des Handlers als konsumiert
gezählt, damit der Handler die Nachricht über eine Exception ablehnen
kann.
Kai Moritz [Mon, 11 Apr 2022 08:51:01 +0000 (10:51 +0200)]
Die Spring-Boot App wird nun sauber herunter gefahren
* Zuvor wurde die App nicht richtig beendet, weil der ExecutorService nicht
beendet wurde und sich die JVM deswegen nicht beenden konnte.
* Dies ist erst durch die Aktivierung des shutdown-Endpoints aufgefallen.
* Jetzt wurde in `Application` eine `@PreDestroy`-Methode ergänzt, die
den ExecutorService nach allen Regeln der Kunst ordentlich beendet.
Kai Moritz [Sat, 9 Apr 2022 09:36:29 +0000 (11:36 +0200)]
Refaktorisierung für Tests - Start des EndlessConsumer in ApplicationRunner
* Bisher wurde der EndlessConsumer beim erzeugen der Bean gestartet
* Dies ist für das Aufsetzen von Tests ungünstig, da die erzeugte Bean
dort nicht unbedingt direkt gestartet werden soll
* Daher wurde der Start des EndlessConsumer in einen ApplicationRunner
ausgelagert
Kai Moritz [Sat, 9 Apr 2022 09:21:43 +0000 (11:21 +0200)]
Refaktorisierung für Tests - KafkaConsumer als eigenständige Bean
* Der KafakConsumer wird als eigenständige Bean erzeugt
* Die Bean wird dem EndlessConsumer im Konstruktor übergeben
* Dafür muss der Lebenszyklus der KafkaConsumer-Bean von dem der
EndlessConsumer-Bean getrennt werden:
** close() darf nicht mehr im finally-Block im EndlessConsumer aufgerufen
werden
** Stattdessen muss close() als Destry-Methode der Bean definiert werden
** Für start/stop muss stattdessen unsubscribe() im finally-Block aufgerufen
werden
** Da unsubscribe() die Offset-Position nicht commited, muss explizit
ein Offsset-Commit beauftragt werden, wenn der Consumer regulär
gestoppt wird (WakeupException)
Kai Moritz [Sun, 10 Apr 2022 17:52:09 +0000 (19:52 +0200)]
Default-Konfiguration überarbeitet
* Eine über die IDE bzw. Maven gestartete Instanz soll klar als solche
erkennbar sein (`client.id` = DEV), darf dafür aber im Compose-Setup
mitspielen (`group.id` = my-group).
* Bisher gab es häufig Port-Konflikte, wenn über die IDE bzw. über Maven
parallel zu einem Compose-Setup eine Instanz gestartet wurde. Daher wird
jetzt hier explizit auf einen abweichenden Port (8881) ausgewichen.
* Im Compose-Setup auch den neuen Port für den Producer übernommen
Kai Moritz [Thu, 7 Apr 2022 10:49:09 +0000 (12:49 +0200)]
Consumer aus der IDE spielt mit
* Sonst läuft bei Experimenten die MongoDB auseinander
* Denn in die schreiben die Docker-Instanzen und die IDE-Instanz
* Deswegen gehört jetzt auch die IDE-Instanz zu der Consumer-Group, die
in Docker-Compose verwendet wird.
* *ANMERKUNG:*
** Da die gezählten Keys jetzt in der MongoDB gespeichert werden, wird
jetzt die Störung der Partitionierung durch die Änderung der Anzahl
der Partitionen wieder sichtbar, _obwohl_ zwischendurch ein Wechsel
der zuständigen Consumer-Instanz erfolgt
** D.h., es wird deutlich, wie sehr Zustand, der aus einer Partition
aufgebaut wird, unter einer Änderung der Partitions-Anzahl leidet!
Kai Moritz [Thu, 7 Apr 2022 07:25:41 +0000 (09:25 +0200)]
Rückbau auf verschachtelte Maps
* Die zuvor erfundenen fachlichen Klassen passen nicht zu dazu, dass man
sie - wie gedacht - direkt in MongoDB stopfen könnte.
* Daher hier erst mal der Rückbau auf Maps, da das dan für die Übungen
einfacher ist.
Kai Moritz [Tue, 5 Apr 2022 20:37:55 +0000 (22:37 +0200)]
Report über gesehene Schlüssel wiederbelebt
* An der alten Stelle war die Map ja jetzt nur noch leer, da dem Consumer
zu dem Zeitpunkt, an dem die gesehen Schlüssel ausgegeben wurden, bereits
alle Partitionen entzogen worden sind.
* Daher werden die gesehenen Schlüssel jetzt ausgegeben, wenn eine
Partition entzogen wird.
Kai Moritz [Fri, 1 Apr 2022 20:02:28 +0000 (22:02 +0200)]
Der Consumer zählt jetzt die Nachrichten pro Key für jedes Topic
* Die Ergebnisse werden beim Beenden des Consumer ausgegeben
* Wenn der Consumer neu gestartet wird, werden die Ergebnisse zurückgesetzt
* Über /seen können Zwischenstände abgefragt werden
Kai Moritz [Fri, 1 Apr 2022 09:40:14 +0000 (11:40 +0200)]
Fehler bei der Erzeugung des KafkaConsumer werden nicht mehr verschluckt
* Beim Erzeugen der Properties-Instanz können Exceptions fliegen
* Beim Erzeugen der KafkaConsumer-Instanz können Exception fliegen
* Daher wurden diese Schritte in den try/catch-Block verlegt
* Neben der Nachricht wird jetzt auch der ganze Stack-Trace gelogged
* Da die Erzeugung des KafkaConsumer jetzt im try/catch-Block geschieht,
wird der EndlessConsumer im Fehlerfall korrekt als beendet markiert