The dynamic discovery protocol combines reconnect logic with the capability to auto-discover broker endpoints in the local network. The discovery protocol invokes a discovery agent in order to build up a list of broker URIs. The protocol then randomly chooses a URI from the list and attempts to establish a connection to it. If it does not succeed, or if it subsequently fails, a new connection is established to one of the other URIs in the list.
A discovery agent is a bootstrap mechanism that enables a message broker, consumer, or producer to obtain a list of broker URIs, where the URIs represent connector endpoints. The broker, consumer, or producer can subsequently connect to one of the URIs in the list.
The following kinds of discovery agent are currently supported in Fuse Message Broker:
Simple (static) discovery agent.
Multicast discovery agent.
Rendezvous discovery agent.
For more details, see Discovery Agents.
Before you can use the discovery protocol, you must make your broker’s endpoints discoverable by adding a discovery agent to each transport connector. The static discovery mechanism is a special case however: you do not need to add a discovery agent to the broker endpoints in order to use a static discovery agent on the client side.
For example, to make a TCP transport connector discoverable, set the
discoveryUri attribute on the
transportConnector element as follows:
Example 1.3. Making a TCP connector discoverable
<transportConnectors>
<transportConnector
name="openwire"
uri="tcp://localhost:61716"
discoveryUri="multicast://default"/>
</transportConnectors>Where the TCP transport connector is configured to use the multicast discovery
agent, multicast://default.
A discovery URI must conform to the following syntax:
discovery://(DiscoveryAgentUri)?TransportOptions
Where the discovery agent URI, DiscoveryAgentUri,
identifies a discovery agent, as described in Discovery agents above. The transport options,
?, are specified
in the form of a query list (where the supported options are described in Table 1.2 ). If no transport options are
required, you can use the following alternative syntax:TransportOptions
discovery://DiscoveryAgentUriThe discovery protocol supports the transport options described in Table 1.2
Table 1.2. Discovery Transport Options
| Option Name | Default | Description |
|---|---|---|
initialReconnectDelay | 10 | How long to wait before the first reconnect attempt (in ms). |
reconnectDelay | 10 | How long to wait for discovery. |
maxReconnectDelay | 30000 | The maximum amount of time to wait between reconnect attempts (in ms). |
useExponentialBackOff | true | If true, use an exponential back-off between
reconnect attempts. |
backOffMultiplier | 2 | The exponent used in the exponential back-off algorithm. |
maxReconnectAttempts | 0 | If not 0, this is the maximum number of
reconnect attempts before an error is sent back to the
client. |
group | default | A group identifier used to partition multicast traffic among collaborating peers; the group forms part of the shared identity of a discovery datagram. |
It is also possible to apply options to the discovered transport by adding those options to the discovery URI. When parsing the URI, the discovery protocol consumes those options that it recognizes (the ones listed in Table 1.2). Any remaining options are held in reserve until a transport is discovered. When the discovered transport is resolved, the remaining options are applied to that transport.
For example, suppose that you expect to discover a TCP endpoint, you can then add
some TCP transport options to your discovery URI. The following discovery URI shows
how to set the connectionTimeout TCP transport option:
discovery://(multicast://default)?connectionTimeout=2000
 |  |  |
 |
