JGroups based distributed command bus

Imported from Google Groups
#1

Hi All,

I intend to run a clustered Axon application. I read about how the distributed command bus will forward all commands for the same aggregate to the same node in my cluster in order to prevent out-of-order processing and locking issues.
There are a few bit and pieces that are not very clear to me however:

  1. JGroup Channels have publish/subscribe semantics so how does a given subscriber now which message it should handle or ignore?
  2. What happens if I add another node to my cluster dynamically: how doesthis affect my RoutingStrategy ? How does Axon spread the commands over N+1 nodes?
    Thanks,

Benoît

#2

Hi,

Axon only uses pub/sub semantics when new nides join, to publish the node’s capabilities to the others. JGroups also allows for peer to peer communication, which is what Axon uses to dispatch messages.

Clients use consistent hashing to define the target node for a command. The RoutingStrategy just defines how to get the input value for the hash from a Command Message. When nodes join, the consistent hash ring changes, but the routing strategy stays the same. The consistent hash algorithm ensured that the new node ‘steals’ a fair share of every other node.

Cheers,

Allard

#3

Allard,

Thanks for clarifying.

I understand the JGroups distributed command bus supports dynamic upscaling of my system (adding nodes).
Can I safely assume it supports dynamic downsizing (remove nodes) too?

Regards,
Benoît

#4

Hi Benoit,

yes, it does. Downscaling it at least as important as upscaling. When nodes scale down cleanly, they report the fact that they leave, and all nodes instantaneously take over the leaving node’s portion of command handling.
When a node leaves without prior notice, there is an amount of time where the node is “suspect”. That typically takes 5 seconds. During that time, some commands may fail to properly find their destination. Senders of these commands will get an exception and have the option to retry. Note that senders also get an exception if the node goes down after a command was sent, but before a result was reported. This exception states that the outcome of the command is unknown.

Cheers,

Allard