Vorlage

Das README-Skript gibt die Header mit aus, damit man den Type-Header sieht

Separate Artefakt-/Image-ID für die JSON-Version des requests-Services

sumup-requests verschickt JSON-Nachrichten mit Hilfe von Spring Kafka

Testfall für Consumer (vorerst?) entfernt

Es sollte eine andere Group-ID voreingestellt sein

* Wenn die selbe Group-ID voreingestellt ist, kommt es bei Experimenten
  schnell dazu, dass die `sumup-requests`-Instanzen der selben Gruppe
  beitreten, wie die `sumup-adder`-Instanzen.
* Dies ist zwar ggf. verwirrend, führt aber _nicht unbedingt_ zu Fehlern,
  da die beiden Services unterschiedliche Topics lesen, so dass sie sich
  nicht wechselseitig die Arbeit streitig machen.
* Es kommt allerdings zu schwer nachvollziehbaren Fehlern, sobald mit
  der Partition-Assignment-Strategy experimentiert wird.
* Denn in diesem Fall kann z.B. `sumup-adder` nicht mehr frei eine
  Strategie wählen, da `sumup-requests` zuvor schon die Protokoll-Version
  `Cooperative` gewählt hat, die nicht rückwärtskompatibel ist.
* D.h., wenn `sumup-adder` später die Strategy `StickyAssignor` wählt,
  bekommt sie nur die verwirrende Meldung, das ein anderes Gruppen-Mitglied
  eine inkompatible Version verwendet.

Versendete Nachrichten an den neuen Kontrakt angepasst

Benennung vereinheitlicht und projektunabhängig gemacht

`requests`-Service für das SumUp-Beispiel implementiert

Verbesserungen gemerged 'counting-consumer' -> 'endless-stream-consumer'

Verbesserungen aus 'rebalance-listener' nach 'counting-consumer' gemerged

Verbesserungen aus 'stored-state' nach 'rebalance-listener' gemerged

In dem Compose-Setup sind nur die übersteuerten Properties eingetragen

Verbesserungen aus 'stored-offsets' nach 'stored-state' gemerged

Der Integration-Test prüft auch, ob der HealthIndicator 'UP' zurückgibt

Integration-Test hinzugefügt, um die Lauffähigkeit der App sicherzustellen

Fixes für Setup/README.sh aus 'deserialization' in 'stored-offsets' gemerged

Compose-Setup und README.sh für dieses Beispiel repariert

* Zuvor war in dem Setup noch ein Producer konfiguriert, der Nachrichten
  vom Typ `String` geschrieben hat, so dass der Consumer _sofort_ das
  zeitliche gesegnet hat.
* Im README-Skript wurde nicht darauf gewartet, dass der Consumer
  gemeldet hat, dass er ordentlich gestartet ist, bevor er nach der
  vermeintlichen Konsumption der Poison-Pill wieder neu gestartet wurde.

Verbesserungen aus 'deserialization' nach 'stored-offsets' gemerged

Refaktorisierungen aus 'wordcount' nach 'stored-offsets' zurück portiert

refactor: Alle Kafka-Belange in den `WordcountRebalanceListener` verschoben

* Dafür neues Interface `PollIntervalAwareRebalanceListener` eingeführt.
* `WordcountRebalanceListener` implementiert das neue Interface und
  kümmert sich um alle Kafka-Belange.
* `WordcountRecordHandler` kümmert sich nur noch um die Fachlogik.

refactor: Handling der Partitionen in WordcountRebalanceListener

refactor: RebalanceListener als eigenständige Klasse

refactor: Implementierung an Branch `stored-offsets` angepasst

Wordcount-Implementierung mit Kafka-Boardmitteln und MongoDB als Storage

* Zählt die Wörter pro Benutzer.
* Simple Implementierung mit Maps.
* Verwendet die bereits für das Speichern der Nachrichten-Zählung und
  der Offsets verwendete MonogoDB-Anbindung zum speichern.
* Typisierung zurückgenommn: Immer String für Key/Value
* Verwendet aus Bequemlichkeit den Seen-Endpoint von der Zählung.

Umstellung des Nachrichten-Datentyps auf Long zurückgenommen

* Im Branch 'deserialization' wurde der Datentyp der Nachricht von `String`
  auf `Long` umgestellt, um eine `DeserializationException` vorzuführen, die
  innerhalb des Kafka-Codes geworfen wird.
* Diese Änderung wurde schon dort nicht in dem `README.sh`-Skript
  reflektiert.
* Hier stört sie jetzt die Experimente mit dem `EndlessProducer`, der
  Nachrichten vom Typ `String` erzeugt, so dass der Consumer kein einzige
  Nachricht annehmen kann.
* Daher wird der Nachrichten-Datentyp hier wieder auf `String` zurück
  umgestellt.
* Dafür musste auch der Testfall angepasst und der Test entfernt werden, der
  die Exception kontrolliert.

Auf den `CooperativeStickyAssignor` umgestellt

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.

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!

Fehler im Shutdown-Code korrigiert: Shutdown von `EndlessConsumer` zu spät

mongo-express sollte erst nach der MongoDB gestartet werden

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.

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.

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).

Verhalten des Testfalls kontrollierbarer gemacht

* Die Awaitility-Aufrufe pollen den zu prüfenden Zustand wenn nicht anders
  angegeben so häufig, wie es die CPU zulässt - also ohne Verzögerung
  zwischen den Überprüfungen.
* Das kann den Rechner temporär so überlasten, dass der erwartete Zustand
  in der abgewarteten Zeit gar nicht eintritt!
* Z.B. aufgetreten, wenn wie hier das Commit-Interval auf 1 Sekunde
  gesetzt ist, das Polling von Awaitility aber noch ungebremst durchgeführt
  wird.
* Um diese Quelle für falsche Fehler auszuschließen, wurde jetzt
  durchgängig ein Poll-Intervall von 1 Sekunde für Awaitility gesetzt.

Testfall überarbeitet

* Abhängigkeit der Testergebnisse von Ausführreihenfolge beseitigt.
* Die Abhängigkeit bestand, da die Offset-Positionen als Zustand die
  Testausführung überdauert haben.
* Daher konnte kein weiterer Test mehr ausgeführt werden, nachdem einmal
  eine Poison-Pill in das Topic geschrieben wurde, über die der
  implementierte Consumer stolpert.
* Um das zu umgehen, werden die Offset-Positionen jetzt nach jedem Test
  auf das Ende der Partitionen verschoben. D.h., wenn in dem Test eine
  Poision-Pill geschrieben wird, über die der implementierte Consumer
  nicht hinweglesen kann, werden die Offests vor der Ausführung des
  nächsten Tests über diese Poision-Pill hinweg gesetzt.
* Dadurch ist wurde ein Fehler / eine Schwäche in der Testlogik aufgedeckt:
  In dem Test für das erfolgreiche Schreiben wurde nur deswegen ein Commit
  ausgeführt, weil zuvor noch kein Commit durchgeführt wurde, so dass der
  Default-Wert für das Commit-Interval immer überschritten war.
* Um das zu umgehen, wurde eine Konfigurations-Option für das Setzen des
  Parameters `auto.commit.interval` eingeführt, so dass im Test
  sichergestellt werden kann, dass auf jeden Fall in dem beobachteten
  Zeitraum ein automatischer Commit ausgelöst wird.
* Außerdem: Weniger verwirrende Ausgabe des Offset-Fortschritts.

Verwendung eines weniger verwirrenden Key in Tests (fachlich irrelevant)

Erzeugung von ProducerRecord in Test refaktorisiert

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.

Merge der überarbeiteten Compose-Konfiguration ('rebalance-listener')

Merge der überarbeiteten Compose-Konfiguration ('stored-state')

README.sh startet MongoDB und Mongo-Express

Merge der überarbeiteten Compose-Konfiguration ('rebalance-listener')

* Dabei auch die letzten Verbesserungen aus 'rebalance-listener' übernommen.

Merge der überarbeiteten Compose-Konfiguration ('counting-consumer')

Merge der überarbeiteten Compose-Konfiguration ('endless-stream-consumer')

* Die letzten Änderungen an 'endless-stream-consumer' sind länger nicht
  mehr gemerged worden.

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.

Merge der Upgrades für Confluent/Spring-Boot (Branch 'first-contact')

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

Fehler in Shutdown-Logik für den `ExecutorService` korrigiert

Merge branch 'rebalance-listener' into deserialization

Merge branch 'endless-stream-consumer' into rebalance-listener

HealthIndicator implementiert: Implementierung selbst vergessen :/

Refactor: `EndlessConsumer` ist selbst ein `ConsumerRebalanceListener`

* Vorbereitung für die Übernahme der Funktionalität in der springifizierten
  Version.

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.

Tests: Refaktorisiert - Serialisierung des Payloads konfigurierbar gemacht

Tests: Tests prüfen den Status des Consumers

Tests: Refaktorisiert - Nachrichten werden für alle Tests aufgezeichnet

Tests: Fehlerfall-Test prüft, dass nicht alle Nachrichten gelesen wurden

Tests: Assert-Beschreibungen korrigiert/ergänzt

Tests: Geprüft, dass der Fehler nach einem Neustart neu vorliegt

Tests: Umbau für einen Commit im Fehlerfall und Anpassung des Tests

Tests: Refaktorisiert - Methoden-Reihenfolge aufgeräumt und kommentiert

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.

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.

Tests: Refaktorisiert - DRY für Test auf Offset-Fortschritt

Tests: Überprüft, ob überhaupt ein Offset-Fortschritt vorliegt

Tests: Offsets werden unter TopicPartition abgelegt

Tests: Test-Reihenfolge definiert, da das Topic nicht geleert wird

Tests: Erste Version eines synchronen Integration-Test implementiert

Demonstration der RecordDeserializationException

* EndlessConsumer wird mit dem Value-Type `Long` anstatt `String` erzeugt
* Setup für die Demonstration der DeserializationException überarbeitet

Refaktorisierung für Tests - EndlessConsumer typisiert

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.

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.

Refaktorisierung für Tests - ExecutorService als separate Bean erzeugt

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

Refaktorisierung für Tests - Bean-Definition in Config-Klasse verschoben

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)

Die Offsets werden ausgegeben, wenn eine Partition zugeteilt/entzogen wird

Gesehene Schlüssel sollten als long gezählt werden

Merge branch 'endless-stream-consumer' into rebalance-listener

HealthIndicator implementiert

shutdown-Endpoint aktiviert

Informationen zur Kafka-Konfiguration im info-Endpoint sichtbar gemacht

Informationen zur Java-Umgebung im info-Endpoint aktiviert

Das Git-Commit-Id-Plugin generiert eine git.properties

Das Spring-Boot-Maven-Plugin generiert Build-Info

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

Falschen Status-Code bei start/stop-Fehler korrigiert

Verständliche Fehlermeldungen für DriverController

Merge branch 'endless-stream-consumer' into rebalance-listener

Thread-Synchronisation bei start/stop überarbeitet

Fehlerbehandlung in EndlessConsumer.destroy() korrigiert

Validierung erfolgt über spring-boot-starter-validation

Merge branch rebalance-listener into counting-consumer

* Nur wegen der Rück-Umbenennung des counting-consumer in endless-consumer
* Die anderen Änderungen aus dem Branch wurden entfernt

Merge branch 'stored-state' into stored-offsets

MongoDB Express zum Compose-Setup hinzugefügt

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!

Merge branch 'rebalance-listener' into stored-state

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.

Offset-Position in der MongoDB wird vor jedem `poll()` aktualisiert