JGroups is an alternative approach to distributing command bus (commands) besides Axon Server.
JGroupsConnectoruses (as the name already gives away) JGroups as the underlying discovery and dispatching mechanism. Describing the features of JGroups is beyond the scope this reference guide Please refer to the JGroups User Guide for more information.
To use the JGroups components from Axon, make sure the
axon-jgroupsmodule is available on the classpath through the preferred dependency management system. When combined with Spring Boot, the
axon-jgroups-spring-boot-starterdependency can be included to enable auto-configuration.
Since JGroups handles both discovery of nodes and the communication between them, the
JGroupsConnectoracts as both a
NoteYou can find the JGroups specific components for the
JGroupsConnectorhas four mandatory configuration elements:
channel- which defines the JGroups protocol stack. Generally, a JChannel is constructed with a reference to a JGroups configuration file. JGroups comes with a number of default configurations which can be used as a basis for your own configuration. Do keep in mind that IP Multicast generally doesn't work in Cloud Services, like Amazon. TCP Gossip is generally a good start in such type of environment.
clusterName- defines the name of the cluster that each segment should register to. Segments with the same cluster name will eventually detect each other and dispatch commands among each other.
localSegment- the Command Bus implementation that dispatches Commands destined for the local JVM. These commands may have been dispatched by instances on other JVMs or from the local one.
serializer- used to serialize command messages before they are sent over the wire.
NoteWhen using a cache, it should be cleared out when the
ConsistentHashchanges to avoid potential data corruption (e.g. when commands do not specify a
@TargetAggregateVersionand a new member quickly joins and leaves the JGroup, modifying the aggregate while it is still cached elsewhere.)
JGroupsConnectorneeds to actually connect in order to dispatch messages to other segments. To do so, call the
JChannel channel = new JChannel("path/to/channel/config.xml");
CommandBus localSegment = SimpleCommandBus.builder().build();
Serializer serializer = XStreamSerializer.builder().build();
JGroupsConnector connector = JGroupsConnector.builder()
DistributedCommandBus commandBus = DistributedCommandBus.builder()
// on one node:
// on another node, with more CPU:
commandBus.updateLoadFactor(150); // defaults to 100
// from now on, just deal with commandBus as if it is local...
NoteNote that it is not required that all segments have command handlers for the same type of commands. You may use different segments for different command types altogether. The distributed command bus will always choose a node to dispatch a command to that has support for that specific type of command.
If you use Spring, you may want to consider using the
JGroupsConnectorFactoryBean. It automatically connects the connector when the
ApplicationContextis started, and does a proper disconnect when the
ApplicationContextis shut down. Furthermore, it uses sensible defaults for a testing environment (but should not be considered production ready) and autowiring for the configuration.
If Spring Boot is used, the configuration can be further simplified by including the
The settings for the JGroups connector are all prefixed with
# enables Axon to construct the DistributedCommandBus
# defines the load factor used for this segment. Defaults to 100
# the address to bind this instance to. By default, it attempts to find the Global IP address
# the port to bind the local instance to
# the name of the JGroups Cluster to connect to
# the JGroups Configuration file to configure JGroups with
# The IP and port of the Gossip Servers (comma separated) to connect to
# when true, will start an embedded Gossip Server on bound to the port of the first mentioned gossip host.