Journeys of a young Software Architect

AspNetCore.IgniteServer: A .NET Core, Kubernetes ready, authentication and SSL enabled Apache Ignite server implementation (extracted from Tarzan and improved)      AspNetCore.IgniteServer.dll is an implementation of Ignite server that references necessary assemblies to provide server-side component for AspNetCore platform. Kubernetes ready, authentication and SSL enabled. Usually, every node runs one or more instances of the server. Usage      The server can be executed with various options: dotnet AspNetCore.IgniteServer.dll [options] Options: -?|-Help Show help information -ConfigFile XML configuration file. If not specified then default configuration is used. -Offheap Size of off-heap memory given in megabytes. -Onheap Size of on-heap memory given in megabytes. -SpiPort Specifies port for Discovery Spi. -Cluster Specifies IP address and port of a cluster node. Multiple nodes can be specified. -Con...

Rebalancer (forked from Jack Vanlightly  and improved)      Create Kafka style consumer groups in other technologies. Rebalancer was born of the need for consumer groups with RabbitMQ. But Rebalancer is completely technology agnostic and will balance activity over any group of resources across a group of participating nodes. Use cases Create Kafka-like "consumer groups" with messaging technologies like RabbitMQ, SQS, etc. Consume a group of resources such as file shares, FTPs, S3 buckets between the instances of a scaled out application. Single Active-Consumer / Active-Backup Create an application cluster that consumes a single resource in a highly available manner. The cluster leader (Coordinator) consumes the single resource and the slaves (Followers) remain idle in backup in case the leader dies. Balancing assignment of multiple resources over multiples nodes Consuming from a single resource with backup nodes in case of failure Concepts ...

     Poison message handling in RabbitMQ it is available as of RabbitMQ 3.8.0, by using the new type of queue:  Quorum Queues .      Quorum queue support handling of poison messages, that is, messages that cause a consumer to repeatedly requeue a delivery (possibly due to a consumer failure) such that the message is never consumed completely and positively acknowledged so that it can be marked for deletion by RabbitMQ.      Be aware, some features are not currently supported by quorum queues:      Quorum queues keep track of the number of unsuccessful delivery attempts and expose it in the "x-delivery-count" header that is included with any redelivered message.      It is possible to set a delivery limit for a queue using a policy argument, delivery-limit. When a message has been returned more times than the limit the message will be dropped or dead-lettered (if a DLX is configu...