[[Messaging_Discovery_Configuration]]
= Configuring Broadcast/Discovery

Each Artemis server can be configured to broadcast itself and/or discovery other Artemis servers within a cluster.
Artemis supports two mechanisms for configuring broadcast/discovery:

== JGroups-based broadcast/discovery

Artemis can leverage the membership of an existing JGroups channel to both broadcast its identity and discover nodes on which Artemis servers are deployed.
WildFly's default full-ha profile uses this mechanism for broadcast/discovery using the default JGroups channel of the server (as defined by the JGroups subsystem).

To add this support to a profile that does not include it by default, use the following:

[source,options="nowrap"]
----
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/broadcast-group=bg-group1:add(jgroups-cluster=activemq-cluster,connectors=http-connector)
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/discovery-group=dg-group1:add(jgroups-cluster=activemq-cluster)
----

To segregate Artemis servers use a distinct membership, configure broadcast/discovery using a separate channel.  To do this, first create the channel resource:

[source,options="nowrap"]
----
[standalone@localhost:9990 /] /subsystem=jgroups/channel=messaging:add(stack=tcp)
----

This creates a new JGroups channel resource based on the "tcp" protocol stack.
Now create your broadcast/discovery groups using this channel:

[source,options="nowrap"]
----
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/broadcast-group=bg-group2:add(jgroups-channel=messaging, jgroups-cluster=activemq-cluster, connectors=http-connector)
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/discovery-group=dg-group2:add(jgroups-channel=messaging, jgroups-cluster=activemq-cluster)
----


== Multicast broadcast/discovery

To broadcast identity to standalone messaging clients, you can additionally configure broadcast/discovery using multicast sockets.

e.g.
[source,options="nowrap"]
----
[standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=messaging(interface=private, multicast-address=230.0.0.4, multicast-port=45689)

[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/broadcast-group=bg-group3:add(socket-binding=messaging, connectors=http-connector)
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/discovery-group=dg-group3:add(socket-binding=messaging)
----


== Cluster behind an HTTP load balancer

If the cluster is behind an HTTP load balancer we need to indicate to the clients that they must not use the cluster topology to connect to it but keep on using the initial connection to the load-balancer.
For this you need to specify on the (pooled) connection factory not to use the topology by setting the attribute "use-topology-for-load-balancing" to false.

[source,options="nowrap"]
----
/subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="use-topology-for-load-balancing", value="false")
----
