Axon - command side scale out

Imported from Google Groups
1

Hi,

I’m pretty new to Axon and evaluating it for a project. I have a question:

Command handler scaleout: I understand that in Axon, the recommended approach is to cluster using Jgroups but each aggregate is only manipulated on one machine. In the event that the machine goes down, this means that the aggregate commands will fail? I understand the motivation to restrict an aggregate to a single machine to avoid concurrency issues - but is there a way to configure some failover mechanism?

Thanks
Raghu

2

Failover uses the exact same mechanism, and is therefore automatically available. When a node goes down, the remaining nodes automatically take over processing of the porting that belonged to the failed node.

It’s not hat a single node will process a certain aggregate, but while the number of servers is constant, commands for the same aggregate area consistently routed to the same machine. That makes caching very beneficial and reduces optimistic locking failures to a minimum.

Cheers,

Allard

3

Thanks a lot for the clarification. Now on to a simple test :slight_smile:

4

Hi,

does this mean that the different nodes need a clustered datastore for the aggregates?

5

Yes, with this setup, that’s indeed the case.

6

Hi - have a follow up:

So here’s what I intend to do but need some validation on how the distributed command bus works

  1. contracts.jar - contains only commands and event definitions.
  2. DomainTodo - jar - contains command handler and eventhandlers for the Todo entity
  3. DomainUsers - jar - contains command and event handlers for User entity
  4. Engine - (refers DomainTodo & DomainUsers),
  • defines a distributed commandbus so that I can run multiple copies of the engine.
  • defines a amqp event bus (rabbit)
  • Event handlers all listen on the event queue for events.
  1. TodoApi(refers contracts) - spring boot REST API that basically takes a payload, forms a command and sends it along its way
  • this is where I have a question - as in this case, the TodoAPI will also have to define a distributed command bus without any commandhandler subscriptions and let JGroups to move the command to the Engine instance (and in my case, since there are multiple Engine processes, based on the target aggregate identifier).

My goal is to separate the REST Api server from the Engine. Does this sound about right?

Thanks!

7

It’s perfectly fine to have a node that doesn’t have handlers of its own. In fact, with a DistributedCommandBus, each node may accept different types of commands.

Cheers,

Allard

8

Thanks Allard. I was able to get it working.