Kai Moritz [Wed, 10 Aug 2022 17:01:04 +0000 (19:01 +0200)]
Der einzige Weg ist, geduldig zu sein...
* Die Logs der Broker sehen so aus, als ob das Topic im Fehlerfall von
diesen als "nie angelegt" betrachtet wird, weil der für das Löschen
des alten Topics zuständige Broker zu früh stopt und beim Neu-Verteilen
dieser Aufgabe fälschlich das unter dem selben Namen neu erzeugte Topic
gelöscht wird.
* Alle Versuche, dies durch Schreiben in das Topic zuverlässig zu
verhindern, sind ins leere gelaufen.
* Helfen tut allein, nach dem Aufruf des `setup`-Services etwas zu
warten, bis sich die Broker alle einig sind.
Kai Moritz [Tue, 2 Aug 2022 17:56:17 +0000 (19:56 +0200)]
Setup und README.sh für rest-producer überarbeitet
* Setup an das Ausgangs-Setup angeglichen.
* Das Setup verwendet jetzt `kafkacat` als Consumer.
* Das README.sh entsprechend der Übung und der Änderungen angepasst.
Kai Moritz [Sat, 23 Jul 2022 09:20:58 +0000 (11:20 +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:38:42 +0000 (20:38 +0200)]
Merge der Upgrades für Confluent/Spring-Boot (Branch 'rest-producer')
* Eigentlich lässt sich hier leichter der Branch 'first-contact' mergen
* Da es aber Verbesserungen des Setups im Branch 'rest-producer' gab,
wurde dieser gemerged.
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 [Sun, 12 Jun 2022 09:57:33 +0000 (11:57 +0200)]
Testfall, der die API aufruft und prüft, ob Nachrichten versendet werden
* Der Testfall verwendet `spring-kafka` als Abhängigkeit mit dem Scope
`test`.
* Dies zeigt ein nicht zu unterschätzendes Anwendungsfeld für Spring
Kafka, seblst wenn das eigentliche Projekt gar nicht auf Spring Kafka
aufsetzt: Einfache Implementierung von Integration-Tests.
Kai Moritz [Sun, 12 Jun 2022 12:50:24 +0000 (14:50 +0200)]
Info-Endpoint des Actuator korrigiert
* Der `kafka`-Eintrag hatte noch den veralteten Parameter `throttle-ms`
des Endless Consumer enthalten
* Der `kafka`-Eintrag hatte noch nicht alle über `ApplicationProperties`
konfigurierbaren Parameter ausgegeben.
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).
* 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 (8880) ausgewichen.
Kai Moritz [Fri, 8 Apr 2022 10:35:31 +0000 (12:35 +0200)]
Setup von counting-consumer auf endless-consumer umgestellt
* Da der Counting-Consumer von den Teilnehmern als Verbesserung des
Endless-Consumer entwickelt wird, sollte dieser auch unter der selben
Artefakt-ID abgelegt wird
* Ansonsten kommt es bei der Ausführung späterer Setups ggf. zu Fehlern,
wenn diese weiterhin die Abweichende Artefakt-ID counting-consumer
enthalten, obwohl folgende Verbesserungen wieder unter endless-consumer
entwickelt wurden!
Kai Moritz [Fri, 8 Apr 2022 10:35:31 +0000 (12:35 +0200)]
Setup von counting-consumer auf endless-consumer umgestellt
* Da der Counting-Consumer von den Teilnehmern als Verbesserung des
Endless-Consumer entwickelt wird, sollte dieser auch unter der selben
Artefakt-ID abgelegt wird
* Ansonsten kommt es bei der Ausführung späterer Setups ggf. zu Fehlern,
wenn diese weiterhin die Abweichende Artefakt-ID counting-consumer
enthalten, obwohl folgende Verbesserungen wieder unter endless-consumer
entwickelt wurden!
Kai Moritz [Sun, 3 Apr 2022 05:45:15 +0000 (07:45 +0200)]
Delivery-Timeout für den REST-Producer herabgesetzt
* Der Timeout für `delivery.timeout.ms` wurde von 2 Minuten auf 20
Sekunden heruntergesetzt
* Grund: Die HTTP-Verbindungen der Clients laufen nach 30 Sekunden in
den Default-Timeout, so dass die Fehler sonst nicht sichtbar werden!
* Achtung: Parallel musste dafür `request.timeout.ms` auf 10 Sekunden
herabgesetzt werden, da `delivery.timeout.ms` größer oder gleich
`request.timeout.ms` + `linger.ms` sein muss!
* Die 10s Spiel zwischen `delivery.timeout.ms` und `request.timeout.ms`
werden für die Übungen benötigt, in denen mit `linger.ms` experimentiert
werden soll...
Kai Moritz [Fri, 25 Mar 2022 09:56:17 +0000 (10:56 +0100)]
EndlessProducer in RestProducer umgearbeitet
* Der Producer nimmt die zu versendende Nachricht über ein POST entgegen
* Als Schlüssel wird der Pfad des POST-Aufrufs verwendet
* Die Anfragen werden mit einem DeferredResult asynchron verarbeitet
* Der Producer antwortet erst mit 200-OK, wenn die Nachricht bestätigt wurde
* Wenn der Broker mit einem Fehler antwortet, wird 500 zurückgegeben
* Wenn der Broker nicht erreicht werden kann, wird 400 zurückgegeben