Search

6.4. Broker Configuration

download PDF

Overview

The examples presented so far have demonstrated how to create brokers with default configuration settings. In practice, you will usually need to customize the broker configurations and this can be done by editing the properties of the corresponding Fabric profiles.

Setting OSGi Config Admin properties

Many of the broker configuration settings can be altered by editing OSGi Config Admin properties (which are organized into collections identified by a persistent ID or PID). For example, consider the broker1 profile created by entering the following fabric:mq-create command:
fabric:mq-create --create-container broker --replicas 1 --networks us-west brokerx
The preceding command creates the new profile, mq-broker-default.brokerx, and assigns this profile to the newly created broker1 container.
Note
The new profile gets the name mq-broker-Group.BrokerName by default. If you want the profile to have the same name as the broker (which was the default in JBoss Fuse version 6.0), you can specify the profile name explicitly using the --profile option.
You can inspect the details of the mq-broker-default.brokerx profile using the fabric:profile-display command, as follows:
JBossFuse:karaf@root> profile-display mq-broker-default.brokerx
    Profile id: broker1
    Version   : 1.0
    Parents   : mq-base
    Associated Containers :

    Container settings
    ----------------------------

    Configuration details
    ----------------------------
    PID: org.fusesource.mq.fabric.server-brokerx
    standby.pool default
    connectors openwire
    broker-name broker1
    data /opt/fuse-fabric/data/broker1
    config zk:/fabric/configs/versions/1.0/profiles/mq-base/broker.xml
    group default
    network us-west
Associated with the org.fusesource.mq.fabric.server-brokerx PID are a variety of property settings, such as network and group. You can now add more properties to this PID to customize the broker configuration.

Setting network connector properties

You can specify additional configuration for network connectors, where the property names have the form network.NetworkPropName. For example, to add the setting, network.bridgeTempDestinations=false, to the PID for brokerx, enter the following console command:
profile-edit --pid org.fusesource.mq.fabric.server-brokerx/network.bridgeTempDestinations=false brokerx
The deployed broker dynamically detects the change to this property and updates the network connector on the fly.

Network connector properties by reflection

Fabric uses reflection to set network connector properties. That is, any PID property of the form network.OptionName can be used to set the corresponding OptionName property on the org.apache.activemq.network.NetworkBridgeConfiguration class. In particular, this implies you can set any of the following network.OptionName properties:
PropertyDefaultDescription
namebridge Name of the network - for more than one network connector between the same two brokers, use different names
userNameNoneUsername for logging on to the remote broker port, if authentication is enabled.
passwordNonePassword for logging on to the remote broker port, if authentication is enabled.
dynamicOnlyfalse If true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on start-up.
dispatchAsynctrueDetermines how the network bridge sends messages to the local broker. If true, the network bridge sends messages asynchronously.
decreaseNetworkConsumerPriority false If true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. If false, all network consumers use same default priority (that is, 0) as local consumers.
consumerPriorityBase-5Sets the starting priority for consumers. This base value will be decremented by the length of the broker path when decreaseNetworkConsumerPriority is set.
networkTTL 1 The number of brokers in the network that messages and subscriptions can pass through (sets both messageTTL and consumerTTL)
messageTTL 1 The number of brokers in the network that messages can pass through.
consumerTTL 1 The number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh).
conduitSubscriptions true Multiple consumers subscribing to the same destination are treated as one consumer by the network.
duplex false If true, a network connection is used both to produce and to consume messages. This is useful for hub and spoke scenarios, when the hub is behind a firewall, and so on.
prefetchSize 1000Sets the prefetch size on the network connector's consumer. It must be greater than 0, because network consumers do not poll for messages
suppressDuplicateQueueSubscriptionsfalseIf true, duplicate subscriptions in the network that arise from network intermediaries are suppressed. For example, consider brokers A, B, and C, networked using multicast discovery. A consumer on A gives rise to a networked consumer on B and C. In addition, C networks to B (based on the network consumer from A) and B networks to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. The networkTTL value needs to match or exceed the broker count to require this intervention.
suppressDuplicateTopicSubscriptionstrueIf true, duplicate network topic subscriptions (in a cyclic network) are suppressed.
bridgeTempDestinations true
Whether to broadcast advisory messages for temporary destinations created in the network of brokers. Temporary destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default, so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most or all of the messages use the request-reply pattern, this generates additional traffic on the broker network, because every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted with an advisory message in the network of brokers).
If you disable this feature, this network traffic can be reduced, but in this case the producers and consumers of a request-reply message need to be connected to the same broker. Remote consumers (that is, connected through another broker in your network) will not be able to send the reply message, but instead will raise a temp destination does not exist exception.
alwaysSyncSend false If true, non-persistent messages are sent to the remote broker using request/reply semantics instead of oneway message semantics. This setting affects both persistent and non-persistent messages the same way.
staticBridgefalse If true, the broker does not respond dynamically to new consumers. It uses only staticallyIncludedDestinations to create demand subscriptions.
useCompressionfalseCompresses the message body when sending it over the network.
advisoryForFailedForwardfalseIf true, send an advisory message when the broker fails to forward the message to the temporary destination across the bridge.
useBrokerNamesAsIdSeedtrueAdd the broker name as a prefix to connections and consumers created by the network bridge. It helps with visibility.
gcDestinationViewstrueIf true, remove any MBeans for destinations that have not been used for a while.
gcSweepTime60000The period of inactivity in milliseconds, after which we remove MBeans.
checkDuplicateMessagesOnDuplexfalseIf true, check for duplicates on the duplex connection.

Broker configuration file

Another important aspect of broker configuration is the ActiveMQ broker configuration file, which is specified as a Spring XML file. In the context of Fabric, this file is stored as a resource in the ZooKeeper registry in the mq-base profile. That is, in the ZooKeeper registry, the broker.xml file is stored in the following location:
/fabric/configs/versions/1.0/profiles/mq-base/broker.xml
This file has the following default contents:
    <beans
      xmlns="http://www.springframework.org/schema/beans"
      xmlns:amq="http://activemq.apache.org/schema/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
      http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">

        <!-- Allows us to use system properties and fabric as variables in this configuration file -->
        <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
            <property name="properties">
                <bean class="org.fusesource.mq.fabric.ConfigurationProperties"/>
            </property>
        </bean>

        <broker xmlns="http://activemq.apache.org/schema/core" brokerName="${broker-name}" dataDirectory="${data}" start="false">

            <destinationPolicy>
                <policyMap>
                  <policyEntries>
                    <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">
                      <pendingSubscriberPolicy>
                        <vmCursor />
                      </pendingSubscriberPolicy>
                    </policyEntry>
                    <policyEntry queue=">" producerFlowControl="true" memoryLimit="1mb">
                    </policyEntry>
                  </policyEntries>
                </policyMap>
            </destinationPolicy>

            <managementContext>
                <managementContext createConnector="false"/>
            </managementContext>

            <persistenceAdapter>
                <kahaDB directory="${data}/kahadb"/>
            </persistenceAdapter>

            <transportConnectors>
                <transportConnector name="openwire" uri="tcp://0.0.0.0:0"/>
            </transportConnectors>
        </broker>

    </beans>
Note that some of the PID properties from the profile are substituted into this template (for example, broker-name and data) and it's important that you reuse them properly. The easiest way to edit this configuration is to use the Fuse Management Console (see "Management Console User Guide") or the built-in profile text editor (see Appendix A, Editing Profiles with the Built-In Text Editor).

Additional broker configuration files

If you like, you can create additional broker configuration files in the mq-base profile, for example:
/fabric/configs/versions/1.0/profiles/mq-base/mybroker.xml
You can then use this custom mybroker.xml configuration by invoking the fabric:mq-create command with the --config option, as follows:
fabric:mq-create --config mybroker.xml brokerx
The --config option assumes that the configuration file is stored in the current version of the mq-base profile, so you need to specify only the file name (that is, the full ZooKeeper path is not required).
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.