WIP:fix:activation

WIP:fix:activation

WIP:TMP:test -- FIX: `ChatRoomData` active/inactive

TMP:test:FIX

TMP:test -- FIX: `ChatRoomData` active/inactive

WAS:TMP:IS?FIX:WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen

WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen

TMP:disable-handoverit

WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen

WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen

WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen

TMP:test -- `ChatRoomDataTest`
--
TODO: Anpassungen an Codeänderungen durch FIX

WIP:test: `*ConfigurationIT` asserts, if restored messages can be seen
--
TODO: Ist der Test so vollständig, bzw. auf dem letzten Stand?

WIP:reconnect

test: HandoverIT - RED - Started a second backend

* A second backend is started, after the writers and the listener were
  instanciated.
* The test fails, because the listener does not see messages, that are
  send by the writers after the rebalance finishes.

fix: GREEN - `ChatRoomData` obeys to the added expectations.

* Switched `ChatRoomData` from a multicast- to a replay-sink.
* Before, listening was implemented with a multicast-sink, that enabled
  back-pressure.
* Now, it was refactored to use a replay-sink, that enables a (configurable)
  limitted replay.

test: RED - Added test for multiple parallel Listeners to `ChatRoomDataTest`

* The test formulates the expectation, that late listeners should see all
  messages (for a reasonable long period before their subscriptions)
* The test _fails_, because the implementation only buffers messages for
  backpressure -- _not for replay!_

chore: The GitHub-Action for the Maven-Build is triggerd for all branches

test: Fixed `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* In the case, that the request that adds a messag failed, the longly
  process of creating a new chat-room, until it has the correct shard,
  was unnecessarily repeated.
* Different workarounds have to be applied at the same time for the two
  implementations:
** Because `ShardedChatHomeService` only throws a `ShardNotOwnedException`,
   if the shard, that is picked by the strategy is not owned, the result
   is retried until the requests succeeds by chance.
** The `KafkaChatHomeService` always creates the chat-room in the
   partition, that is derived from the randomly picked id.
   Hence, the loop, that is only left, if the randomly picked partition
   matches the partition `2`, that the test-instance owns.
** Since `SimpleChatHomeService` does not know the concept of sharding
   at all, the loop is also left, if no shard is set (shard is ``null``).

test: Refined `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* Removed unnecessary asserts: the expected result of the creation of a
  chat-room is no concern of this test.
* Simplified the assertion of the shard.

test: Fixed `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* The first request in the awaited assertion must create a chat-room,
  that is owned by the instance.
* Hence, _it has to_ assert, that the shard of the created chat-room is
  `2` - the only shard, the test-instance owns, or _empty_, if the instance
  under test does not implement sharding.

test: Added tests for listening to `ChatRoomDataTest`

test: Refactored `ChatRoomDataTest` - made mocking more clear

* When mocking the results of calls to `ChatMessageService`, the returned
  message does naturally _not_ reflect the parameters of the call.
* Hence, a arbitrary message is used whenever the test only asserts,
  that a value, that was returened by `ChatMessageService` is handed
  through as expected by `ChatRoomData`.

test: Removed unnecessary Mockito-recordings in `ChatRoomDataTest`

test: `ChatRoomDataTest` verifies that persistence is triggered as expected

test: Refactored `ChatRoomDataTest` - DRY for message attributes

chore: activated IT in GitHUB-Maven-Build

chore: Create maven.yml

test: HandoverIT-POC - Refactored `TestListener`

test: HandoverIT-POC - Added logging for complete/error to listener

test: HandoverIT-POC - Waiting for the assertion when all messages are sent

test: HandoverIT-POC - Refactored the startup of backend-containers

* The backend-containers are explicitly started during the test.
* When a backend is started, it is waited for, that the started backend
  reportes its status as `UP`, _and_, that alle writers are again able to
  send messages, afterwards.

refactor: Simplified the configuration for the kafka-services

* Removed class `ChannelTaskRunner` and `KafkaServicesApplicationRunner`.
* Instead, the method `ChannelTaskExecutor.excuteChannelTask()` is executed
  as `@Bean.initMethod` by Spring.
* Adapted the test-cases accordingly:
** Joinig the channel-tasks is not necessary any more, because that is
   done by the imported production-config
** `KafkaConfigurationIT` has to call `executeChannelTasks()`
   explicitly
** Therefore, it has to overrule the default-config for the bean
   `dataChannelTaskExecutor` in order to drop the configuration of the
   `initMethod`.
** Otherwise, the test would (might) not restore the data from the topic,
   because the messages, that are send into the test-cluster, might arrive
   only after the initial loading of the data is done.

refactor: Removed config-dependencies from `ChannelTaskExecutor`

refactor: Simplified shutdown - channel-tasks were joined multiple times

* `KafkaServicesApplicationRunner` does not have to join the channel-tasks.
* The channel-tasks are already joined by `ChannelTaskExecutor.join()`
  automatically, because the method is annotated with `@PreDestroy`.
* Simplified the test-configuration accordingly.

fix: The shutdown of the application was blocked

* The auto-configured bean `applicationTaskExecutor` must not block, while
  it is shutting down, because otherwise, it infinitly waits for the
  completion, of the channel-tasks, which are stopped in a _later_ phase
  of the "smart" lifecycle.
* The bean is destroyed first, becaus it is is associated with the lowest
  lifecyle-phase (``Integer.MAX_VALUE``), which apparently cannot be
  overruled by `@DependsOn` (although suggested by the spring-
  documentation)
* Joining the channel-tasks was blocking infinitly, because the tasks were
  waiting for the kafka-consumers to be closed, what only happens _after_
  the joining completes.

fix: Detection of the `READY`-state for `InfoChannel` was flawed

feat: Implemented and configured health-indicator for the ``Channel``s

refactor: Refined channel-states, introduced `ChannelState` -- ALIGN

* Renamed attributes and method-names according to the class-renames.
* Introduced interface `Channel` and `enum ChannelState`.
* `Data` - and `InfoChannel` maintain a `ChannelState`, instead just a
  plain boolean, that only reflects the loading-state.
* The `ChannelTaskRunner` waits, until both channels entered the State
  `ChannelState.SHUTTING_DOWN`.

refactor: Refined channel-states, introduced `ChannelState` -- MOVE

* Renamed and moved `LoadInProgressException`
** Moved exception into implementation-specific package
** Renamed exception to `ChannelNotReadyException`
* Renamed `ConsumerTaskExecutor` into `ChannelTaskExecutor`
* Renamed `ConsumerTaskRunner` into `ChannelTaskRunner`

test: HandoverIT-POC - Added assertions for the sent/received messages

test: HandoverIT-POC - fix for the blocking wait for `TestListener`

* Droped the waiting for `TestListener` alltogehter.
* The waiting can be droped, because waiting for the `TestWriter`-instances
  ensures, that all messages are send (and therefore very likely received)

test: HandoverIT-POC - working fix: using `delayElements()`

* Switched from `Flux.flatMap(Mono.delay()..)` to
  `Flux.from(..).delayElements()`FIX:delay_vs_delayElements.
* This delays eache element of the `Flux` by the same amount.
* The requests are made, when the according element of the flux is
  executed - not when the `Flux` is created, as before.

test: HandoverIT-POC - not working fix: using `delay()`

* Switched from `Mono.from(..).delayElement()` to `Mono.delay().then()`.
* This does _not_ solve the problem, that all delays are calculated and
  scheduled, when the `Flux` is created.

test: HandoverIT-POC - FIX: `take(n)`, does end the work after n elements

* `take(n)` does end the execution.
* `limitRate(n)` limits the rate of requested elements.

test: HandoverIT-POC - Executing the Flux/Mono asynchrounusly

test: HandoverIT-POC - Listener/Writer remember received/sent messages

test: HandoverIT-POC - Refactored listening into class `TestListener`

test: HandoverIT-POC - Refactored `TestWriter` to use a `Flux`

test: HandoverIT-POC - Each `TestWriter` writes only to one chat-room

test: HandoverIT-POC - Refactored / Cleaned up

test: HandoverIT-POC - Renamed `TestClient` to `TestWriter` -- ALIGN

test: HandoverIT-POC - Renamed `TestClient` to `TestWriter` -- MOVE

test: HandoverIT-POC - Fixed illegal client-naming (one character only)

test: HandoverIT-POC - Fixed logging of failed client-requests

fix: Fixed `ConcurrentModificationException` when accessing a chat-room

* If a new chat-room was created, `InfoChannel` only reacted with the
  creation of the according `ChatRoomInfo`-instance.
* The creation of the accompanying `ChatRoomData`-instance through
  `DataChannel` was posponed until the new chat-room was accessed the
  first time.
* That way, `InfoChannel` did not need to know `DataChannel`, so that a
  cyclic dependency could be avoided.
* As a downside, this approach was open to a race-condition: if several
  accesses to the newly created chat-room happend in parallel, a
  `ConcurrentModificationException` was thrown, since the instance of
  `ChatRoomData` was created multiple times in parallel.
* To circumvent the locking, that would be necesarry to evade this race
  condition, the approach was refactored, so that `InfoChannel` now
  explicitly triggers the creation of the `ChatRoomData`-instance.
* To do so without introducing a cyclic dependency, the class
  `ChannelMediator` was introduced, so that `InfoChannel` and `DataChannel`
  need not to know each other.

refactor: Introduced `ChannelMediator`

* `InfoChannel` and `DataChannel` must not know each other directly.
* This is necessary, to prevent a cyclic dependency, that would otherwise
  be introduced, if `InfoChannel` also has to communicate with
  `DataChannel`.

test: HandoverIT-POC - clients are stopped after some time

test: HandoverIT-POC - running multiple clients in parallel

test: HandoverIT-POC - added a delay to the sending-loop

test: HandoverIT-POC - remodeled sending into a for-loop

test: HandoverIT-POC - messages are written to 23 chat-rooms instead of 1

test: HandoverIT-POC - splitted up code into smaller classes -- ALIGN

test: HandoverIT-POC - splitted up code into smaller classes -- MOVE

test: HandoverIT-POC - Moved general container-defs into base-class

test: HandoverIT-POC - setup without static containers

test: HandoverIT-POC - first working setup for the planned test

* First working POC of the setup for the planned test.
* This version blocks endlessly, because the SSE-flux never completes.

fix: Errors during shard-publishing should not kill the instance

* `HaproxyShardingPublisherStrategy` has to transform any exception into
  a `Mono.error()`.
* `DataChannel.onPartitionsAssigned(..)` has to log and swallow errors
  during the propagation of the shard-ownership.

fix: Sensible value for sink-buffer

feat: Made polling-interval for Kafka configurable

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

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