-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for Red Hat Fuse
6.4. Broker Configuration
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 --network 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: io.fabric8.mq.fabric.server-brokerx
standby.pool default
connectors openwire
broker-name broker1
data /opt/fuse-fabric/data/broker1
config profile:broker.xml
group default
network us-west
Associated with the
io.fabric8.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 io.fabric8.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:
| Property | Default | Description |
|---|---|---|
name | bridge | Name of the network - for more than one network connector between the same two brokers, use different names |
userName | None | Username for logging on to the remote broker port, if authentication is enabled. |
password | None | Password for logging on to the remote broker port, if authentication is enabled. |
dynamicOnly | false | If true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on start-up. |
dispatchAsync | true | Determines 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 | -5 | Sets 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 | 1000 | Sets the prefetch size on the network connector's consumer. It must be greater than 0, because network consumers do not poll for messages |
suppressDuplicateQueueSubscriptions | false | If 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. |
suppressDuplicateTopicSubscriptions | true | If 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. |
staticBridge | false | If true, the broker does not respond dynamically to new consumers. It uses only staticallyIncludedDestinations to create demand subscriptions. |
useCompression | false | Compresses the message body when sending it over the network. |
advisoryForFailedForward | false | If true, send an advisory message when the broker fails to forward the message to the temporary destination across the bridge. |
useBrokerNamesAsIdSeed | true | Add the broker name as a prefix to connections and consumers created by the network bridge. It helps with visibility. |
gcDestinationViews | true | If true, remove any MBeans for destinations that have not been used for a while. |
gcSweepTime | 60000 | The period of inactivity in milliseconds, after which we remove MBeans. |
checkDuplicateMessagesOnDuplex | false | If 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="io.fabric8.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).
