Zugriffe eine `ShardNotOwnedException` erzeugt.
- Dadurch wird das Zustands-Handling *extrem vereinfacht*, da Anfragen,
die *während* einem Rebalance auflaufen
+- *Lade-Modus - Initialisierung und Abschluss-Bedingung:*
+ - Wenn durch einen Rebalance in den Lade-Modus gewechselt wird, muss die
+ *tatsächliche* Offset-Position der zuletzt geschriebenen Nachrichten
+ für die zugeordneten Partitionen ermittelt werden.
+ - Anschließend wird ein Seek auf die Offset-Position 0 (später: auf die
+ in den lokalen Daten gespeicherte Offset-Position) durchgeführt.
+ - Der Lade-Modus ist abgeschlossen, wenn für alle zugeordneten Partitionen
+ der zum Rebalance-Zeitpunkt ermittelte Offset der aktuellsten Nachrichten
+ erreicht ist.
+ - Wenn ein weiterer Rebalance erfolgt, während der Lade-Modus bereits
+ aktiv ist, sollte es genügen, die Informationen über die zugeordneten
+ Partitionen zu aktualisieren und die Aktuellen Offsets für diese neu
+ zu ermitteln.
+- *Lade-Modus vs. Default-Modus:*
+ - Nur während des Lade-Modus *liest* die `KafkaChatRoomServcie`-Instanz
+ tatsächlich die Nachrichten aus den zugeordneten Partitionen.
+ - Im Default-Modus *schreibt* sie die Nachrichten nur in die Partitionen
+ und speichert sie lokal ab, sobald die *Bestätigung durch den `Producer`*
+ erfolgt.
+ - D.h. insbesondere, dass der `KafkaConsumer` im Default-Modus für alle
+ zugeordneten Partitionen *pausiert* wird!
+ - Damit die Offset-Positon nicht unnötig zurückfällt, sollte ggf.
+ regelmäßig für alle zugeordneten Partitionen ein Seek auf die zuletzt
+ vom Producer bestätigt geschriebenen Offsets durchgeführt werden.
+ - *Beachte:_ Dies ist nicht nötig, wenn die Offsets eh in den lokal
+ gespeicherten Daten gehalten und aus diesen wiederhergestellt werden!
- *Umsetzungs-Details:*
- Da die in dem Interface `ConsumerRebalanceListener` definierten Methoden
in einem zeitkritischem Setting laufen, muss das eigentliche Laden der
projects / demos / kafka / chat / blobdiff