[[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")
----
