230 lines
10 KiB
Markdown
230 lines
10 KiB
Markdown
# Core Bridges
|
|
|
|
The function of a bridge is to consume messages from a source queue, and
|
|
forward them to a target address, typically on a different Apache ActiveMQ Artemis
|
|
server.
|
|
|
|
The source and target servers do not have to be in the same cluster
|
|
which makes bridging suitable for reliably sending messages from one
|
|
cluster to another, for instance across a WAN, or internet and where the
|
|
connection may be unreliable.
|
|
|
|
The bridge has built in resilience to failure so if the target server
|
|
connection is lost, e.g. due to network failure, the bridge will retry
|
|
connecting to the target until it comes back online. When it comes back
|
|
online it will resume operation as normal.
|
|
|
|
In summary, bridges are a way to reliably connect two separate Apache ActiveMQ Artemis
|
|
servers together. With a core bridge both source and target servers must
|
|
be Apache ActiveMQ Artemis servers.
|
|
|
|
Bridges can be configured to provide *once and only once* delivery
|
|
guarantees even in the event of the failure of the source or the target
|
|
server. They do this by using duplicate detection (described in [Duplicate Detection](duplicate-detection.md)).
|
|
|
|
> **Note**
|
|
>
|
|
> Although they have similar function, don't confuse core bridges with
|
|
> JMS bridges!
|
|
>
|
|
> Core bridges are for linking an Apache ActiveMQ Artemis node with another Apache ActiveMQ Artemis
|
|
> node and do not use the JMS API. A JMS Bridge is used for linking any
|
|
> two JMS 1.1 compliant JMS providers. So, a JMS Bridge could be used
|
|
> for bridging to or from different JMS compliant messaging system. It's
|
|
> always preferable to use a core bridge if you can. Core bridges use
|
|
> duplicate detection to provide *once and only once* guarantees. To
|
|
> provide the same guarantee using a JMS bridge you would have to use XA
|
|
> which has a higher overhead and is more complex to configure.
|
|
|
|
## Configuring Bridges
|
|
|
|
Bridges are configured in `broker.xml`. Let's kick off
|
|
with an example (this is actually from the bridge example):
|
|
|
|
<bridge name="my-bridge">
|
|
<queue-name>jms.queue.sausage-factory</queue-name>
|
|
<forwarding-address>jms.queue.mincing-machine</forwarding-address>
|
|
<filter-string="name='aardvark'"/>
|
|
<transformer-class-name>
|
|
org.apache.activemq.artemis.jms.example.HatColourChangeTransformer
|
|
</transformer-class-name>
|
|
<retry-interval>1000</retry-interval>
|
|
<ha>true</ha>
|
|
<retry-interval-multiplier>1.0</retry-interval-multiplier>
|
|
<initial-connect-attempts>-1</initial-connect-attempts>
|
|
<reconnect-attempts>-1</reconnect-attempts>
|
|
<failover-on-server-shutdown>false</failover-on-server-shutdown>
|
|
<use-duplicate-detection>true</use-duplicate-detection>
|
|
<confirmation-window-size>10000000</confirmation-window-size>
|
|
<user>foouser</user>
|
|
<password>foopassword</password>
|
|
<static-connectors>
|
|
<connector-ref>remote-connector</connector-ref>
|
|
</static-connectors>
|
|
<!-- alternative to static-connectors
|
|
<discovery-group-ref discovery-group-name="bridge-discovery-group"/>
|
|
-->
|
|
</bridge>
|
|
|
|
In the above example we have shown all the parameters its possible to
|
|
configure for a bridge. In practice you might use many of the defaults
|
|
so it won't be necessary to specify them all explicitly.
|
|
|
|
Let's take a look at all the parameters in turn:
|
|
|
|
- `name` attribute. All bridges must have a unique name in the server.
|
|
|
|
- `queue-name`. This is the unique name of the local queue that the
|
|
bridge consumes from, it's a mandatory parameter.
|
|
|
|
The queue must already exist by the time the bridge is instantiated
|
|
at start-up.
|
|
|
|
> **Note**
|
|
>
|
|
> If you're using JMS then normally the JMS configuration
|
|
> `activemq-jms.xml` is loaded after the core configuration file
|
|
> `broker.xml` is loaded. If your bridge is
|
|
> consuming from a JMS queue then you'll need to make sure the JMS
|
|
> queue is also deployed as a core queue in the core configuration.
|
|
> Take a look at the bridge example for an example of how this is
|
|
> done.
|
|
|
|
- `forwarding-address`. This is the address on the target server that
|
|
the message will be forwarded to. If a forwarding address is not
|
|
specified, then the original address of the message will be
|
|
retained.
|
|
|
|
- `filter-string`. An optional filter string can be supplied. If
|
|
specified then only messages which match the filter expression
|
|
specified in the filter string will be forwarded. The filter string
|
|
follows the ActiveMQ Artemis filter expression syntax described in [Filter Expressions](filter-expressions.md).
|
|
|
|
- `transformer-class-name`. An optional transformer-class-name can be
|
|
specified. This is the name of a user-defined class which implements
|
|
the `org.apache.activemq.artemis.core.server.cluster.Transformer` interface.
|
|
|
|
If this is specified then the transformer's `transform()` method
|
|
will be invoked with the message before it is forwarded. This gives
|
|
you the opportunity to transform the message's header or body before
|
|
forwarding it.
|
|
|
|
- `ha`. This optional parameter determines whether or not this bridge
|
|
should support high availability. True means it will connect to any
|
|
available server in a cluster and support failover. The default
|
|
value is `false`.
|
|
|
|
- `retry-interval`. This optional parameter determines the period in
|
|
milliseconds between subsequent reconnection attempts, if the
|
|
connection to the target server has failed. The default value is
|
|
`2000`milliseconds.
|
|
|
|
- `retry-interval-multiplier`. This optional parameter determines
|
|
determines a multiplier to apply to the time since the last retry to
|
|
compute the time to the next retry.
|
|
|
|
This allows you to implement an *exponential backoff* between retry
|
|
attempts.
|
|
|
|
Let's take an example:
|
|
|
|
If we set `retry-interval`to `1000` ms and we set
|
|
`retry-interval-multiplier` to `2.0`, then, if the first reconnect
|
|
attempt fails, we will wait `1000` ms then `2000` ms then `4000` ms
|
|
between subsequent reconnection attempts.
|
|
|
|
The default value is `1.0` meaning each reconnect attempt is spaced
|
|
at equal intervals.
|
|
|
|
- `initial-connect-attempts`. This optional parameter determines the
|
|
total number of initial connect attempts the bridge will make before
|
|
giving up and shutting down. A value of `-1` signifies an unlimited
|
|
number of attempts. The default value is `-1`.
|
|
|
|
- `reconnect-attempts`. This optional parameter determines the total
|
|
number of reconnect attempts the bridge will make before giving up
|
|
and shutting down. A value of `-1` signifies an unlimited number of
|
|
attempts. The default value is `-1`.
|
|
|
|
- `failover-on-server-shutdown`. This optional parameter determines
|
|
whether the bridge will attempt to failover onto a backup server (if
|
|
specified) when the target server is cleanly shutdown rather than
|
|
crashed.
|
|
|
|
The bridge connector can specify both a live and a backup server, if
|
|
it specifies a backup server and this parameter is set to `true`
|
|
then if the target server is *cleanly* shutdown the bridge
|
|
connection will attempt to failover onto its backup. If the bridge
|
|
connector has no backup server configured then this parameter has no
|
|
effect.
|
|
|
|
Sometimes you want a bridge configured with a live and a backup
|
|
target server, but you don't want to failover to the backup if the
|
|
live server is simply taken down temporarily for maintenance, this
|
|
is when this parameter comes in handy.
|
|
|
|
The default value for this parameter is `false`.
|
|
|
|
- `use-duplicate-detection`. This optional parameter determines
|
|
whether the bridge will automatically insert a duplicate id property
|
|
into each message that it forwards.
|
|
|
|
Doing so, allows the target server to perform duplicate detection on
|
|
messages it receives from the source server. If the connection fails
|
|
or server crashes, then, when the bridge resumes it will resend
|
|
unacknowledged messages. This might result in duplicate messages
|
|
being sent to the target server. By enabling duplicate detection
|
|
allows these duplicates to be screened out and ignored.
|
|
|
|
This allows the bridge to provide a *once and only once* delivery
|
|
guarantee without using heavyweight methods such as XA (see [Duplicate Detection](duplicate-detection.md) for
|
|
more information).
|
|
|
|
The default value for this parameter is `true`.
|
|
|
|
- `confirmation-window-size`. This optional parameter determines the
|
|
`confirmation-window-size` to use for the connection used to forward
|
|
messages to the target node. This attribute is described in section
|
|
[Reconnection and Session Reattachment](client-reconnection.md)
|
|
|
|
> **Warning**
|
|
>
|
|
> When using the bridge to forward messages to an address which uses
|
|
> the `BLOCK` `address-full-policy` from a queue which has a
|
|
> `max-size-bytes` set it's important that
|
|
> `confirmation-window-size` is less than or equal to
|
|
> `max-size-bytes` to prevent the flow of messages from ceasing.
|
|
|
|
- `producer-window-size`. This optional parameter determines the
|
|
producer flow control through the bridge. You usually leave this off
|
|
unless you are dealing with huge large messages.
|
|
|
|
Default=-1 (disabled)
|
|
|
|
- `user`. This optional parameter determines the user name to use when
|
|
creating the bridge connection to the remote server. If it is not
|
|
specified the default cluster user specified by `cluster-user` in
|
|
`broker.xml` will be used.
|
|
|
|
- `password`. This optional parameter determines the password to use
|
|
when creating the bridge connection to the remote server. If it is
|
|
not specified the default cluster password specified by
|
|
`cluster-password` in `broker.xml` will be used.
|
|
|
|
- `static-connectors` or `discovery-group-ref`. Pick either of these
|
|
options to connect the bridge to the target server.
|
|
|
|
The `static-connectors` is a list of `connector-ref` elements
|
|
pointing to `connector` elements defined elsewhere. A *connector*
|
|
encapsulates knowledge of what transport to use (TCP, SSL, HTTP etc)
|
|
as well as the server connection parameters (host, port etc). For
|
|
more information about what connectors are and how to configure
|
|
them, please see [Configuring the Transport](configuring-transports.md).
|
|
|
|
The `discovery-group-ref` element has one attribute -
|
|
`discovery-group-name`. This attribute points to a `discovery-group`
|
|
defined elsewhere. For more information about what discovery-groups
|
|
are and how to configure them, please see [Discovery Groups](clusters.md).
|
|
|
|
|