WIP:poc-setup

WIP:poc-setup

WIP:fix-sse

fix: Sensible value for sink-buffer

feat: Made polling-interval for Kafka configurable

WIP:wait

WIP:FIX

WIP:loading

WIP:wait--FIX

WIP:wait--FIX

WIP:wait--FIX

WIP:wait

WIP:wait

WIP:wait

WIP:wait

WIP:setup

WIP:setup

WIP:setup

fix: The number of chards is the number of partitions of the `data_channel`

WIP:setup

WIP:setup

WIP:setup

WIP:startup

WIP:startup

WIP:startup

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP:neu

WIP

wIP

WIP

WIP

WIP

WIP

fix: Disabled mongodb-autoconfig, if mongodb is not used

feat: Switched to `spring-boot-starter-data-mongodb-reactive`

feat: Added logging for io.projectreactor to `MongoDbStorageStrategy`

refactor: DRY for logging-category from io.projectreactor

feat: Added counting of restored instances

test: `StorageStrategy`-IT are restoring instead of recreating

fix: GREEN - Fixed the restore-mechanism

* The code of a reactive flow _must not_ call blocking functions.
* In order to solve this, the restore-process is triggered explicitly
  after the creation of the classes.

refactor: RED - Refined success/error-handling for restore-operations

* This innocent little change discloses a severe missconception in the
  implementation of the storage strategies.
* The call to `Mono.block()`, though not really changing the behaviour
  during the restore-process, triggers a sanity-check from
  io.projectractor.

test: Simplified the integration-tests for `StorageStrategy`

test: Simplified `InMemoryWithMongoDbStorageIT`

* Switched to `@ServiceConnection` instead of hand-coded initializer.

test: Added IT for `ChatRoomRepository` and `MessageRepository`

test: Simplified & Unified the Kafka-tests

test: Simplified `ChatHomeServiceTest`

* Removed the unnecessary explicit instantiation of the `ObjectMapper`.

test: Simplified & unified test-setup for ``ChatHomeServiceTest``s

* Using existing configuration-classes instead of hand-coded configuartion.
* Aligned the `KafkaChatHomeServiceTest` with the `in-memory`-tests.

refactor: Cleaned up code

feat: Introduced counting of stored instances in `StorageStrategy`

feat: Introduced config-parameters for the `io.projectreactor`-logging

refactor: Set logging-level for io.projectreactor to `DEBUG`

refactor: Refined stream-definition in `StorageStrategy#write`

* Changed the stream-definition to a more natural order.
* As a result, the stored `ChatRoomInfo`-instances do not have to be
  handed clumsily to the following stream.

refactor: Refined return-type of `StorageStrategy#write`

refactor: One stream -> using `flatMap` instead of an inner `subscribe`

refactor: Moved succes/error-logging to outer stream-definitions

refactor: Simplified `StorageStrategy`

* Reconfigurable success/error-logging was introduced for
  `NoStorageStorageStrategy`.
* But as it turns out, this strategy can simply apply its logging in the
  overwritten method, that disables the whole storing-logic.
* Hence, the interface was greatly simplified again, by removing this
  ununsed mechanism.

refactor: Moved extracted the `subscribe()`-call from `StorageStrategy`

* The subscription does no more happen inside the implementations of the
  interface `StorageStrategy`.
* Instead, the methods, that are defined in `StorageStrategy` return the
  created `Flux`.
* The call to `subscribe()` happens in the code, that uses this methods.
* This faciliates feature refinements concerning the asynchronous handling
  of success- and error-cases and so forth.

refactor: Extracted subscription into a separate method-call

* This is in preparation to a planed refinement.
* The refinment will move the `subscribe()`-call out of the implementation
  of the `StorageStrategy`.

test: Added missing JSR-310 module to not Spring-Boot-based tests

feat: Added log message for disabled storage

fix: Without `@DirtiesContext` the app is not teared down correctly

* `StorageStrategy` depends on Spring to call the method
  `ChatBackendApplication#onExit()`, that is annotated with `@PreDestroy`.
* If this method is not called, the strategy is not applied, which leads
  to errors in the integration-tests.
* This happens, if all tests are run through Maven, because Spring
  recycles the application-context and only tears down the context after
  all tests have run.
* The addition of `@DirtiesContext` on those tests forces Spring to tear
  down the application completely after each so annotated test.
* Hence, the method is called as expected, which fixes the described
  errors.

test: Introduced integration-tests for `NoStorageStorageStrategy`
--
ALIGN

test: Introduced integration-tests for `NoStorageStorageStrategy`
--
COPY

refactor: Extracted annonymous class into `NoStorageStorageStrategy`
--
ALIGN

refactor: Extracted annonymous class into `NoStorageStorageStrategy`
--
COPY

refactor: Added success- and failure-callbacks for `ChatHomeService`

refactor: Added success- and failure-callbacks to `StorageStrategy`

refactor: `KafkaServicesApplicationRunner` aufgeräumt

fix: Config-ITs do not fail, if run multiple times

fix: Removed manual version-management for testcontainers.org

feat: Upgraded Spring Boot 3.1.3 -> 3.2.2

fix: `getChatRoomInfo()` thrwos `LoadInProgressException` when loading

- The method `InfoChannel.getChatRoomInfo(UUID)` has to check, if loading
  is in process.
- Otherwise, an existing chat-room might erronously not be found, if it is
  requested, while `InfoChannel` is loading, because it is not yet loaded.

refactor: compute `loadInProgress` on offset-change

refactor: separated message- and record- (aka offset-) handling

refactor: Renamed method in `InfoChannel` according to conventions

refactor: Made only locally used method in `KafkaChatHomeService` private

feat: The position of the last seen messages is stored on a revoke

fix: The actual position has to be requested from the consumer

* If the last seen offset and the current offset differ, although the
  partition did not contain any messages between this offsets, the loading
  process got stuck, because the position never advanced.
* Therefore, the actual position, that is compared against the read
  end-offset, has to be requested from the consumer.

refactor: Added logging of loaded messages

refactor: Refined success/error-handling when publishing shard-ownership

feat: Implemented `HaproxyShardingPublisherStrategy`

* Implemented a first simple `ShardingPublisherStrategy`, that uses the
 https://www.haproxy.com/documentation/haproxy-runtime-api/[HAProxy Runntime API]
 to publish changed ownerships.
* Added configuration-properties `kafka.haproxyRuntimeApi` and
  `kafka.haproxyMap` to configure the strategy.

feat: Introduced interface `ShardingPublisherStrategy`

* The interface is used by `DataChannel` to publish the changed ownership
  each time, a new partition is assigned to the consumer-group.
* Added a dummy-implementation in `KafkaServicesConfiguration`.

feat: Introduced a configurable instance-id

fix: `ConsumerTaskRunner` waits until the data-loading is finished

feat: Introduced events that are send, if a shard is assigned/revoked

* In order to redirect requests to the appropriate instances, each
  instance must know the mapping from  shard-IDs to instance-URIs.
** For the static `in-memory`-implementation `ShardedChatHomeService`,
   this is a static mapping, that can be configured and read on start-up.
** For the dynamic `KafkaChatHomeService`, this mapping has to be
   propageted to all instances each time the partition-assignment of the
   consumer-group changes.
* Changes for `ShardedChatHomeService`
** Introduced `ChatBackendProperties.shardOwners` (of type `URI[]`).
** Each instance reads the static mapping from shard-ID to instance-URI
   on start-up.
* Changes for `KafkaChatHomeService`
** Introduced `KafkaServicesProperties.instanceUri` (of type `URI`).
** Each instance reads its URI on start-up.
** `DataChannel` sends an event for each assigned/removed partition,
   when the partition-assignment of the consumer-group changes.
** These events propagete the changed mapping from partition-ID to
   instance-URI.
** `InfoChannel` receives these events and updates the dynamic mapping
   from partition-ID (aka:shard-ID) to instance-URI.
* The shards, that are owned by an instance, can be queried via `/shards`.

fix: `metadata` is never `null`

refactor: DRY for computation of new `ChatRoomData` instances

fix: GREEN - `DataChannel` creates entries for existent chat-rooms

test: RED - Putting a message in a newly created chat-room

refactor: Splitted test in `AbstractConfigurationIT` into smaler pieces