+ +

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).

+
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.
+
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 +2000milliseconds.
+
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-intervalto 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 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
+
+
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.
+
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.
+

+ + +

+ +

results matching ""

+ +

No results matching ""

+ +

+ + Core Bridges +

Core Bridges

Configuring Bridges

results matching ""

No results matching ""

+ + Diverting and Splitting Message Flows +

Diverting and Splitting Message Flows

Exclusive Divert

Non-exclusive Divert

results matching ""

No results matching ""