demos/kafka/demos-kafka-payment-system-transfer
11 days agoWIP master
Kai Moritz [Mon, 15 Nov 2021 20:41:03 +0000 (21:41 +0100)]
WIP

4 months agoThe restore-process no longer happens inside onPartitionsAssigned()
Kai Moritz [Sun, 27 Jun 2021 13:19:42 +0000 (15:19 +0200)]
The restore-process no longer happens inside onPartitionsAssigned()

4 months agoPrepared for the development of version 2.2.0
Kai Moritz [Fri, 25 Jun 2021 19:45:48 +0000 (21:45 +0200)]
Prepared for the development of version 2.2.0

4 months agoReleased version 2.1.0
Kai Moritz [Fri, 25 Jun 2021 19:43:42 +0000 (21:43 +0200)]
Released version 2.1.0

4 months agoBugfix: Check for existence of a new transfer requires a remote-call
Kai Moritz [Fri, 25 Jun 2021 14:15:53 +0000 (16:15 +0200)]
Bugfix: Check for existence of a new transfer requires a remote-call

* The _local_ check for the existens of a transfer to create possibly leads
  to a NPE in this version, because it access the TransferRepository for a
  partition, not regarding, if it is available locally.
* This access simply lead to no result before, but since the in-memory
  maps for the partitions are now created only, when the partition is
  assigned, it causes a NPE now.
* The local check, that does not make a lot of sence since the service
  was refactored to run on multiple insances in parallel, is replaced
  against a remote call here.

4 months agoState must only be stored locally, if the corresponding offset is known
Kai Moritz [Tue, 29 Jun 2021 18:56:39 +0000 (20:56 +0200)]
State must only be stored locally, if the corresponding offset is known

4 months agoThe state is periodically stored in a local file, that is read on startup
Kai Moritz [Tue, 29 Jun 2021 18:51:54 +0000 (20:51 +0200)]
The state is periodically stored in a local file, that is read on startup

4 months agoRefined the feedback-messages of the TransferConsumer
Kai Moritz [Fri, 25 Jun 2021 08:50:02 +0000 (10:50 +0200)]
Refined the feedback-messages of the TransferConsumer

4 months agoPrepared for the development of version 2.1.0
Kai Moritz [Wed, 23 Jun 2021 20:27:14 +0000 (22:27 +0200)]
Prepared for the development of version 2.1.0

4 months agoReleased version 2.0.0
Kai Moritz [Wed, 23 Jun 2021 20:26:10 +0000 (22:26 +0200)]
Released version 2.0.0

4 months agoSwitched from single-node (assign) to multi-instance (subscribe)
Kai Moritz [Sun, 20 Jun 2021 17:51:13 +0000 (19:51 +0200)]
Switched from single-node (assign) to multi-instance (subscribe)

* TransferConsumer uses subscribe() instead of assign().
* The subscription happens during the instanciation of TransferConsumer.
* The restorage-process of the state happens in onPartitionsAssigned().
* To be able to reset all data, that belongs to a specific partition
  after a rebalance, in order to avoid state errors because of handling
  events several times, InMemoryTransferRepository must know, which
  partition a transfer belongs to.
* To achieve this, the partitioning algorithm is made known explicitly.
* On each rebalance, a mapping from the partions to the currently assigned
  instances is maintained.
* TransferController uses the explicitly known partitioning algorithm, to
  look up the partion for a requested transfer and decide, if the data is
  available locally.
* If not, it looks up the assigned instance in the maintained mapping and
  redirects the request.

5 months agoProperties are only accessible via getters
Kai Moritz [Wed, 23 Jun 2021 20:10:19 +0000 (22:10 +0200)]
Properties are only accessible via getters

5 months agoSimplified the thread-execution
Kai Moritz [Sun, 20 Jun 2021 13:29:27 +0000 (15:29 +0200)]
Simplified the thread-execution

5 months agoPrepared for the development of version 2.0.0
Kai Moritz [Sat, 19 Jun 2021 15:43:13 +0000 (17:43 +0200)]
Prepared for the development of version 2.0.0

5 months agoReleased version 1.1.0
Kai Moritz [Sat, 19 Jun 2021 15:42:37 +0000 (17:42 +0200)]
Released version 1.1.0

5 months agoIgnoring poision pills with illeagal state-changes
Kai Moritz [Sun, 20 Jun 2021 11:59:00 +0000 (13:59 +0200)]
Ignoring poision pills with illeagal state-changes

5 months agoImplemented state-change logic
Kai Moritz [Sat, 19 Jun 2021 15:36:49 +0000 (17:36 +0200)]
Implemented state-change logic

5 months agoMoved TransferService into package ports
Kai Moritz [Sat, 19 Jun 2021 12:51:25 +0000 (14:51 +0200)]
Moved TransferService into package ports

5 months agoMoved all business logic into TransferService
Kai Moritz [Sat, 19 Jun 2021 08:53:31 +0000 (10:53 +0200)]
Moved all business logic into TransferService

5 months agoAutomatically rebuild the state after a crash / restart
Kai Moritz [Tue, 15 Jun 2021 18:27:20 +0000 (20:27 +0200)]
Automatically rebuild the state after a crash / restart

* Turning of enable.auto.commit and setting auto.offset.reset to earliest
  does the trick in this setup.
* Since no offset-commits are made, all events are re-read on startup.
* The TransferConsumer uses a special instance of TransferService, that
  is initialized with a NoOpMessageService, to replay the restored
  events without generating new events.

5 months agoIntroduced different Events for the creation and the state-changes
Kai Moritz [Sat, 19 Jun 2021 07:11:08 +0000 (09:11 +0200)]
Introduced different Events for the creation and the state-changes

5 months agoTransferConsumer logs the number of polled records only, when positive
Kai Moritz [Fri, 18 Jun 2021 14:56:57 +0000 (16:56 +0200)]
TransferConsumer logs the number of polled records only, when positive

5 months agoTransferController sends a message, instead of calling TransferService
Kai Moritz [Sat, 19 Jun 2021 07:08:24 +0000 (09:08 +0200)]
TransferController sends a message, instead of calling TransferService

5 months agoTransferRepository does not need any synchronization
Kai Moritz [Sun, 13 Jun 2021 21:40:56 +0000 (23:40 +0200)]
TransferRepository does not need any synchronization

* Only TransferService stores data in the repository
* Since alle instances of Transfer, that are handled by TransferService
  are received through a single topic, no synchronization is needed at
  all in the repository.
* This is, because records, that are received from a topic are guaranteed
  to be processed one after the other.
* The topic simply is the single source for processing requests and a
  KafkaConsumer never handles multiple records in parallel.
* Note: This implementation is not ready to run on multiple threads or
  nodes!

5 months agoPrepared for development of version 1.1.0
Kai Moritz [Tue, 15 Jun 2021 21:30:44 +0000 (23:30 +0200)]
Prepared for development of version 1.1.0

5 months agoReleased version 1.0.0
Kai Moritz [Sat, 19 Jun 2021 15:40:50 +0000 (17:40 +0200)]
Released version 1.0.0

5 months agoThe build of the docker-image is not triggerd automatically
Kai Moritz [Sun, 13 Jun 2021 11:56:28 +0000 (13:56 +0200)]
The build of the docker-image is not triggerd automatically

5 months agoAdded config/assets to build a docker-image
Kai Moritz [Sun, 13 Jun 2021 09:26:00 +0000 (11:26 +0200)]
Added config/assets to build a docker-image

5 months agoMVP for transfer service
Kai Moritz [Fri, 11 Jun 2021 11:17:02 +0000 (13:17 +0200)]
MVP for transfer service