Reference: Configure Bridges
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 hornetq-jms.xml is loaded after the core configuration file hornetq-configuration.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 HornetQ filter expression syntax described in Chapter 14, 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.hornetq.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. 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. 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 Chapter 37, Duplicate Message 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 Chapter 34, Client Reconnection and Session Reattachment Warning When using the bridge to forward messages 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. connector-ref. This mandatory parameter determines which connector pair the bridge will use to actually make the connection to the target server. 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 Chapter 16, Configuring the Transport. The connector-ref element can be configured with two attributes: connector-name. This references the name of a connector defined in the core configuration file hornetq-configuration.xml. The bridge will use this connector to make its connection to the target server. This attribute is mandatory. backup-connector-name. This optional parameter also references the name of a connector defined in the core configuration file hornetq-configuration.xml. It represents the connector that the bridge will fail-over onto if it detects the live server connection has failed. If this is specified and failover-on-server-shutdown is set to true then it will also attempt failover onto this connector if the live target server is cleanly shut-down. 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 hornetq-configuration.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 hornetq-configuration.xml will be used.