Due to a known issue do not use JDK1.8.0_151 with WSO2 products. Use JDK 1.8.0_144 until JDK 1.8.0_162-ea is released.
This documentation is for WSO2 Message Broker version 3.2.0. For the latest documentation, see the documentation for WSO2 Enterprise Integrator.
Skip to end of metadata
Go to start of metadata

The broker.xml file located in the <MB_HOME>/repository/conf directory contains the configurations relating to optimization, messaging transports, persistent store information, performance tuning and cluster coordination.

This file is compliant with the Cipher Tool.

The following is a tree of the XML elements in the file:

 Click to expand the default broker.xml file
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
  ~ Copyright (c) 2015, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
  ~
  ~ WSO2 Inc. licenses this file to you under the Apache License,
  ~ Version 2.0 (the "License"); you may not use this file except
  ~ in compliance with the License.
  ~ You may obtain a copy of the License at
  ~
  ~    http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing,
  ~ software distributed under the License is distributed on an
  ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  ~ KIND, either express or implied. See the License for the
  ~ specific language governing permissions and limitations
  ~ under the License.
  -->
<!-- This is the root configuration file of WSO2 Message Broker (MB). Links to configurations of 
associated libraries are also specified here. 
[Note for developers] - If you intend to rename or modify a property name, remember to update 
relevant, org.wso2.andes.configuration.enums.AndesConfiguration, enum value using the Xpath 
expression of the property.
This file is ciphertool compliant. Refer PRODUCT_HOME/repository/conf/security/cipher-text.properties for examples.-->
<broker>
    <coordination>
        <!-- You can override the cluster node identifier of this MB node using the nodeID. 
        If it is left as "default", the default node ID will be generated for it. (Using IP + UUID).
        The node ID of each member should ALWAYS be unique.-->
        <nodeID>default</nodeID>
        <!-- Thrift is used to maintain and sync slot (message groups) ranges between MB nodes. -->
        <thriftServerHost>localhost</thriftServerHost>
        <thriftServerPort>7611</thriftServerPort>
        <thriftSOTimeout>0</thriftSOTimeout>
        <!--Thrift server reconnect timeout. Value specified in SECONDS-->
        <thriftServerReconnectTimeout>5</thriftServerReconnectTimeout>
        <!-- Hazelcast reliable topics are used to share all notifications across the MB cluster (e.g. subscription
        changes), And this property defines the time-to-live for a notification since its creation. (in Seconds) -->
        <clusterNotificationTimeout>10</clusterNotificationTimeout>
        <!-- Configurations related RDBMS based coordination algorithm -->
        <rdbmsBasedCoordination enabled="true">
            <!-- Heartbeat interval used in the RDBMS base coordination algorithm in milliseconds -->
            <heartbeatInterval>5000</heartbeatInterval>
            <!-- Time to wait before informing others about coordinator change in milliseconds. This value should be
            larger than a database read time including network latency and should be less than heartbeatInterval -->
            <coordinatorEntryCreationWaitTime>3000</coordinatorEntryCreationWaitTime>
            <!-- Time interval used to poll database for membership related events in milliseconds. -->
            <eventPollingInterval>4000</eventPollingInterval>
        </rdbmsBasedCoordination>
        <!-- Enabling this will make the cluster notifications such as Queue changes(additions and deletions),
        Subscription changes, etc. sent within the cluster be synchronized using RDBMS. If set to false, Hazelcast
        will be used for this purpose.-->
        <rdbmsBasedClusterEventSynchronization enabled="true">
            <!--Specifies the interval at which, the cluster events will be read from the database. Needs to be
            declared in milliseconds. Setting this to a very low value could downgrade the performance where as
            setting this to a large value could increase the time taken for a cluster event to be synchronized in
            all the nodes in a cluster.-->
            <eventSyncInterval>1000</eventSyncInterval>
        </rdbmsBasedClusterEventSynchronization>
    </coordination>
    <!-- You can enable/disable specific messaging transports in this section. By default all 
    transports are enabled. This section also allows you to customize the messaging flows used 
    within WSO2 MB. NOT performance related, but logic related. -->
    <transports>
        <amqp enabled="true">
            <bindAddress>0.0.0.0</bindAddress>
            <defaultConnection enabled="true" port="5672" />
            <sslConnection enabled="true" port="8672">
                <keyStore>
                     <location>repository/resources/security/wso2carbon.jks</location>
                     <password>wso2carbon</password>
                     <certType>SunX509</certType>
                </keyStore>
                <trustStore>
                    <location>repository/resources/security/client-truststore.jks</location>
                    <password>wso2carbon</password>
                    <certType>SunX509</certType>
                </trustStore>
            </sslConnection>
            <maximumRedeliveryAttempts>10</maximumRedeliveryAttempts>
            <allowSharedTopicSubscriptions>false</allowSharedTopicSubscriptions>
            <allowStrictNameValidation>true</allowStrictNameValidation>
            <!-- Refer repository/conf/advanced/qpid-config.xml for further AMQP-specific configurations.-->
        </amqp>
        <mqtt enabled="true">
            <bindAddress>0.0.0.0</bindAddress>
            <defaultConnection enabled="true" port="1883" />
            <sslConnection enabled="true" port="8883">
                <keyStore>
                    <location>repository/resources/security/wso2carbon.jks</location>
                    <password>wso2carbon</password>
                    <certType>SunX509</certType>
                </keyStore>
                <trustStore>
                    <location>repository/resources/security/client-truststore.jks</location>
                    <password>wso2carbon</password>
                    <certType>SunX509</certType>
                </trustStore>
            </sslConnection>
            <!--All receiving events/messages will be in this ring buffer. Ring buffer size
            of MQTT inbound event disruptor. Default is set to 32768 (1024 * 32)
            Having a large ring buffer will have a increase memory usage and will improve performance
            and vise versa -->
            <inboundBufferSize>32768</inboundBufferSize>
            <!-- Messages delivered to clients will be placed in this ring buffer. 
            Ring buffer size of MQTT delivery event disruptor. Default is set to 32768 (1024 * 32)
            Having a large ring buffer will have a increase memory usage and will improve performance
            and vise versa -->
            <deliveryBufferSize>32768</deliveryBufferSize>
            
            <security>
                   <!--
                       Instructs the MQTT server whether clients should always send credentials
                       when establishing a connection.
                       Possible values:
                        OPTIONAL: This is the default value. MQTT clients may or may not send 
                                  credentials. If a client sends credentials server will 
                                  validates it. 
                                  If client doesn't send credentials then server will not 
                                  authenticate, but allows client to establish the connection. 
                                  This behavior adheres to MQTT 3.1 specification.
                        REQUIRED: Clients should always provide credentials when connecting. 
                                  If client doesn't send credentials or they are invalid 
                                  server rejects the connection.
                   -->
                   <authentication>OPTIONAL</authentication>
                  
                   <!--Class name of the authenticator to use. class should 
                       inherit from org.dna.mqtt.moquette.server.IAuthenticator
                       Note: default implementation authenticates against carbon user store
                       based on supplied username/password
                   --> 
                   <authenticator class="org.wso2.carbon.andes.authentication.andes.CarbonBasedMQTTAuthenticator"/>
                    <!--authenticator class="org.wso2.carbon.andes.authentication.andes.OAuth2BasedMQTTAuthenticator">
                        <property name="hostURL">https://localhost:9443/services/OAuth2TokenValidationService</property>
                        <property name="username">admin</property>
                        <property name="password">admin</property>
                        <property name="maxConnectionsPerHost">10</property>
                        <property name="maxTotalConnections">150</property>
                    </authenticator-->
                    <!--
                       Instructs the MQTT server whether clients should be authorized before either publishing or subscribing
                       Possible values:
                        NOT_REQUIRED: This is the default value. MQTT clients will skip the authorization check
                        REQUIRED: Clients will authorized before publishing. this will execute the class given in authorzier
                        Note: authentication should be REQUIRED for authorization to be REQUIRED.
                   -->
                    <authorization>NOT_REQUIRED</authorization>
                    <!--Class name of the authorizer to use. class should
                        inherit from org.dna.mqtt.moquette.server.IAutherizer
                        Note: default implementation authorizes against carbon permission with the topic.
                    -->
                    <!--connectionPermission is required for a user to connect to broker-->
                    <authorizer class="org.wso2.carbon.andes.authorization.andes.CarbonPermissionBasedMQTTAuthorizer">
                        <property name="connectionPermission">/permission/admin/mqtt/connect</property>
                    </authorizer>
            </security>
        </mqtt>
    </transports>
    <!-- Depending on the database type selected in master-datasources.xml, you must enable the
    relevant Data access classes here. Currently WSO2 MB Supports RDBMS(any RDBMS store). 
	These stores are accessed for two purposes.
	
    1. For message persistence ("messageStore")
    2. To persist and access other information relevant to messaging protocols.("contextStore").-->
    <!-- By default WSO2 MB runs with H2 persistent store. If you plan to use a different
    store, point to the relevant dataSource or uncomment the database appropriately.
    RDBMS
    =====
    If you are running an RDBMS you can use the existing RDBMS implementation of stores
    by pointing to the correct data source by updating the property "dataSource".
    Data source entry should be present in
    <MB_HOME>/repository/conf/datasources/master-datasources.xml.
    -->
    <persistence>
        <!-- RDBMS MB Store Configuration -->
        <messageStore class="org.wso2.andes.store.rdbms.RDBMSMessageStoreImpl">
            <property name="dataSource">WSO2MBStoreDB</property>
            <property name="storeUnavailableSQLStateClasses">08</property>
            <property name="integrityViolationSQLStateClasses">23,27,44</property>
            <property name="dataErrorSQLStateClasses">21,22</property>
            <property name="transactionRollbackSQLStateClasses">40</property>
        </messageStore>
        <contextStore class="org.wso2.andes.store.rdbms.RDBMSAndesContextStoreImpl">
            <property name="dataSource">WSO2MBStoreDB</property>
            <property name="storeUnavailableSQLStateClasses">08</property>
            <property name="integrityViolationSQLStateClasses">23,27,44</property>
            <property name="dataErrorSQLStateClasses">21,22</property>
            <property name="transactionRollbackSQLStateClasses">40</property>
        </contextStore>
        <cache>
            <!-- Size of the messages cache in MBs. Setting '0' will disable the cache. -->
            <size>256</size>
            <!-- Expected concurrency for the cache (4 is guava default) -->					
            <concurrencyLevel>4</concurrencyLevel>
            <!--Number of seconds cache will keep messages after they are 
                              added (unless they are consumed and deleted).-->					
            <expirySeconds>2</expirySeconds>
            <!--Reference type used to hold messages in memory.
                    weak   - Using java weak references ( - results higher cache misses)
                    strong - ordinary references ( - higher cache hits, but not good if server 
                             is going to run with limited heap size + under severe load).
            -->
            <valueReferenceType>strong</valueReferenceType>
            <!--Prints cache statistics in 2 minute intervals 
                                                   in carbon log ( and console)-->					
            <printStats>false</printStats>
        </cache>
        <!-- This class decides how unique IDs are generated for the MB node. This id generator is
        expected to be thread safe and a implementation of interface
        org.wso2.andes.server.cluster.coordination.MessageIdGenerator
        NOTE: This is NOT used in MB to generate message IDs. -->
        <idGenerator>org.wso2.andes.server.cluster.coordination.TimeStampBasedMessageIdGenerator</idGenerator>
        <!-- This is the Task interval (in SECONDS) to check whether communication 
        is healthy between message store (/Database) and this server instance. -->
        <storeHealthCheckInterval>10</storeHealthCheckInterval>
    </persistence>
    <!--Publisher transaction related configurations.-->
    <transaction>
        <!--Maximum batch size (Messages) in kilobytes for a transaction. Exceeding this limit will
         result in a failure in the subsequent commit (or prepare) request. Default is set to 1MB.
         Limit is calculated considering the payload of messages.-->
        <maxBatchSizeInKB>10240</maxBatchSizeInKB>
        <!-- Maximum number of parallel dtx enabled channel count. Distributed transaction
         requests exceeding this limit will fail. -->
        <maxParallelDtxChannels>20</maxParallelDtxChannels>
    </transaction>
    <!-- This section allows you to tweak memory and processor allocations used by WSO2 MB.
    Broken down by critical processes so you have a clear view of which parameters to change in
    different scenarios.  -->
    <performanceTuning>
        <slots>
            <!--Rough estimate for size of a slot. What is meant by size is the number of messages
            contained within bounties of a slot. -->
            <windowSize>1000</windowSize>
            <!--
            If message publishers are slow, time taken to fill the slot (up to <windowSize>) will be longer.
            This will add an latency to messages. Therefore broker will mark the slot as
            ready to deliver before even the slot is entirely filled after specified time.
            NOTE: specified in milliseconds.
            -->
            <messageAccumulationTimeout>2000</messageAccumulationTimeout>
            <!-- Time interval which broker check for slots that can be marked as 'ready to deliver' 
                 (- slots which have a aged more than 'messageAccumulationTimeout')
                 NOTE: specified in milliseconds.
            -->
            <maxSubmitDelay>1000</maxSubmitDelay>
            <!--Number of MessageDeliveryWorker threads that should be started-->
            <deliveryThreadCount>5</deliveryThreadCount>
            <!-- Number of parallel threads to execute slot deletion task. Increasing this value will remove slots
                 whose messages are read/delivered to consumers/acknowledged faster reducing heap memory used by
                 server.-->
            <deleteThreadCount>5</deleteThreadCount>
            <!-- Max number of pending message count to delete per Slot Deleting Task. This config is used to raise
             a WARN when pending scheduled number of slots exceeds this limit (indicate of an  issue that can lead to
             message accumulation on server.-->
            <SlotDeleteQueueDepthWarningThreshold>1000</SlotDeleteQueueDepthWarningThreshold>
            <!-- Maximum number of thrift client connections that should be created in the thrift connection pool -->
            <thriftClientPoolSize>10</thriftClientPoolSize>
        </slots>
        <delivery>
            <!-- Maximum number of undelivered messages that can have in memory. Increasing this
            value increase the possibility of out of memory scenario but performance will be
            improved -->
            <maxNumberOfReadButUndeliveredMessages>1000</maxNumberOfReadButUndeliveredMessages>
            <!-- This is the ring buffer size of the delivery disruptor. This value should be a
            power of 2 (E.g. 1024, 2048, 4096). Use a small ring size if you want to reduce the
            memory usage. -->
            <ringBufferSize>4096</ringBufferSize>
            <!--Number of parallel readers used to used to read content from message store.
            Increasing this value will speed-up the message sending mechanism. But the load
            on the data store will increase. -->
            <parallelContentReaders>5</parallelContentReaders>
            <!-- Number of parallel decompression handlers used to decompress messages before send to subscribers.
            Increasing this value will speed-up the message decompressing mechanism. But the system load
            will increase. -->
            <parallelDecompressionHandlers>5</parallelDecompressionHandlers>
            <!-- Number of parallel delivery handlers used to send messages to subscribers.
            Increasing this value will speed-up the message sending mechanism. But the system load
            will increase. -->
            <parallelDeliveryHandlers>5</parallelDeliveryHandlers>
            <!-- The size of the batch represents, at a given time the number of messages that could 
            be retrieved from the database. -->
            <contentReadBatchSize>65000</contentReadBatchSize>
            <contentCache>
                <!-- Specify the maximum number of entries the cache may contain. -->
                <maximumSize>100</maximumSize>
                <!-- Specify the time in seconds that each entry should be 
                     automatically removed from the cache after the entry's creation. -->
                <expiryTime>120</expiryTime>
            </contentCache>
            <!--When delivering topic messages to multiple topic 
                subscribers one of following stratigies can be choosen.
            
               1. DISCARD_NONE     - Broker do not loose any message to any subscriber. 
                                     When there are slow subscribers this can cause broker 
                                     go Out of Memory.
               2. SLOWEST_SUB_RATE - Broker deliver to the speed of the slowest
                                     topic subscriber. This can cause fast subscribers
                                     to starve. But eliminate Out of Memory issue.
               3. DISCARD_ALLOWED  - Broker will try best to deliver. To eliminate Out
                                     of Memory threat broker limits sent but not acked message 
                                     count to <maxUnackedMessages>. 
                                     If it is breached, and <deliveryTimeout> is also 
                                     breached message can either be lost or actually 
                                     sent but ack is not honoured.
            -->
            <topicMessageDeliveryStrategy>
                <strategyName>DISCARD_NONE</strategyName>
                <!-- If you choose DISCARD_ALLOWED topic message delivery strategy, 
                     broker keep messages in memory until ack is done until this timeout.
                     If an ack is not received under this timeout, ack will be simulated 
                     internally and real acknowledgement is discarded.
                     deliveryTimeout is in seconds -->
                <deliveryTimeout>60</deliveryTimeout>
            </topicMessageDeliveryStrategy>
        </delivery>
        <ackHandling>
            <!--Number of message acknowledgement handlers to process acknowledgements concurrently.
            These acknowledgement handlers will batch and process acknowledgements.  -->
            <ackHandlerCount>1</ackHandlerCount>
            <!--Maximum batch size of the acknowledgement handler. Andes process acknowledgements in
            batches using Disruptor Increasing the batch size reduces the number of calls made to
            database by MB. Depending on the database optimal batch size this value should be set.
            Batches will be of the maximum batch size mostly in high throughput scenarios.
            Underlying implementation use Disruptor for batching hence will batch message at a
            lesser value than this in low throughput scenarios -->
            <ackHandlerBatchSize>100</ackHandlerBatchSize>
            <!-- Message delivery from server to the client will be paused temporarily if number of
            delivered but unacknowledged message count reaches this size. Should be set considering
            message consume rate. This is to avoid overwhelming slow subscribers. -->
            <maxUnackedMessages>1000</maxUnackedMessages>
        </ackHandling>
        <contentHandling>
            <!-- Within Andes there are content chunk handlers which convert incoming large content
            chunks into max content chunk size allowed by Andes core. These handlers run in parallel
            converting large content chunks to smaller chunks.
            If the protocol specific content chunk size is different from the max chunk size allowed
            by Andes core and there are significant number of large messages published, then having
            multiple handlers will increase performance. -->
            <contentChunkHandlerCount>3</contentChunkHandlerCount>
            <!-- Andes core will store message content chunks according to this chunk size. Different
            database will have limits and performance gains by tuning this parameter.
            For instance in MySQL the maximum table column size for content is less than 65534, which
            is the default chunk size of AMQP. By changing this parameter to a lesser value we can
            store large content chunks converted to smaller content chunks within the DB with this
            parameter. -->
            <maxContentChunkSize>65500</maxContentChunkSize>
            <!-- This is the configuration to allow compression of message contents, before store messages
            into the database.-->
            <allowCompression>false</allowCompression>
            <!-- This is the configuration to change the value of the content compression threshold (in bytes).
            Message contents less than this value will not compress, even compression is enabled. The recommended
            message size of the smallest message before compression is 13bytes. Compress messages smaller than
            13bytes will expand the message size by 0.4% -->
            <contentCompressionThreshold>1000</contentCompressionThreshold>
        </contentHandling>
        <inboundEvents>
            <!--Number of parallel writers used to write content to message store. Increasing this
            value will speed-up the message receiving mechanism. But the load on the data store will
            increase.-->
            <parallelMessageWriters>1</parallelMessageWriters>
            <!--Size of the Disruptor ring buffer for inbound event handling. For publishing at
            higher rates increasing the buffer size may give some advantage on keeping messages in
            memory and write.
            NOTE: Buffer size should be a value of power of two -->
            <bufferSize>65536</bufferSize>
            <!--Maximum batch size of the batch write operation for inbound messages. MB internals
            use Disruptor to batch events. Hence this batch size is set to avoid database requests
            with high load (with big batch sizes) to write messages. This need to be configured in
            high throughput messaging scenarios to regulate the hit on database from MB -->
            <messageWriterBatchSize>70</messageWriterBatchSize>
            <!--Timeout for waiting for a queue purge event to end to get the purged count. Doesn't
            affect actual purging. If purge takes time, increasing the value will improve the
            possibility of retrieving the correct purged count. Having a lower value doesn't stop
            purge event. Getting the purged count is affected by this -->
            <purgedCountTimeout>180</purgedCountTimeout>
            <!--Number of parallel writers used to write content to message store for transaction
            based publishing. Increasing this value will speedup commit duration for a transaction.
            But the load on the data store will increase.-->
            <transactionMessageWriters>1</transactionMessageWriters>
        </inboundEvents>
        <!--Message expiration can be set for each messages which are published to Wso2 MB.
         After the expiration time, the messages will not be delivered to the consumers. Eventually
         they got deleted inside the MB.-->
        <messageExpiration>
            <!-- When messages delivered, in the delivery path messages were checked whether they are
            already expired. If expired at that time add that message to a queue for a future batch
            delete. This interval decides on the time gap between the batch deletes. Time interval
            specified in seconds.-->
            <preDeliveryExpiryDeletionInterval>10</preDeliveryExpiryDeletionInterval>
            <!-- Periodically check the database for new expired messages which were not assigned to
             any slot delivery worker so far and delete them. This interval decides on the time gap between
             the periodic message deletion. Time interval specified in seconds.-->
            <periodicMessageDeletionInterval>900</periodicMessageDeletionInterval>
            <!-- When checking the database for expired messages, the messages which were handled by the slot
            delivery worker should no be touched since that mess up the slot delivery worker functionality.
            Those messages anyways get caught at the message delivery path. So there is a need to have a safe
            buffer of slots which can be allocated to a slot delivery worker in the near future. The specified
            number of slots from the last assigned should not be touched by the periodic deletion task.-->
            <safetySlotCount>3</safetySlotCount>
        </messageExpiration>
    </performanceTuning>
    <!-- This section is about how you want to view messaging statistics from the admin console and
    how you plan to interact with it. -->
    <managementConsole>
        <!--Maximum number of messages to be fetched per page using Andes message browser when browsing
        queues/dlc -->
        <messageBrowsePageSize>100</messageBrowsePageSize>
        <!-- This property defines the maximum message content length that can be displayed at the
        management console when browsing queues. If the message length exceeds the value, a
        truncated content will be displayed with a statement "message content too large to display."
        at the end. default value is 100000 (can roughly display a 100KB message.)
        * NOTE : Increasing this value could cause delays when loading the message content page.-->
        <maximumMessageDisplayLength>100000</maximumMessageDisplayLength>
        <!--Enable users to reroute all messages from a specific destination(queue or durable topic) to a specific
        queue.-->
        <allowReRouteAllInDLC>true</allowReRouteAllInDLC>
    </managementConsole>
    <!-- Memory and resource exhaustion is something we should prevent and recover from.
    This section allows you to specify the threshold at which to reduce/stop frequently intensive
    operations within MB temporarily. -->
	<!--
	highLimit - flow control is enabled when message chunk pending to be handled by inbound 
	 disruptor reaches above this limit
    lowLimit - flow control is disabled (if enabled) when message chunk pending to be handled
	 by inbound disruptor reaches below this limit	
	-->	
    <flowControl>
        <!-- This is the global buffer limits which enable/disable the flow control globally -->
        <global>
            <lowLimit>800</lowLimit>
            <highLimit>8000</highLimit>
        </global>
        <!-- This is the channel specific buffer limits which enable/disable the flow control locally.
		-->
        <bufferBased>
            <lowLimit>100</lowLimit>
            <highLimit>1000</highLimit>
        </bufferBased>
    </flowControl>
	
    <!--
    Message broker keeps track of all messages it has received as groups. These groups are termed
    'Slots' (To know more information about Slots and message broker install please refer to online wiki).
    Size of a slot is loosely determined by the configuration <windowSize> (and the number of
    parallel publishers for specific topic/queue). Message broker cluster (or in single node) keeps
    track of slots which constitutes for a large part of operating state before the cluster went down.
	When first message broker node of the cluster starts up, it will read the database to recreate
    the internal state to previous state. 
    -->
    <recovery>
        <!--
        There could be multiple storage queues worked before entire cluster (or single node) went down.
        We need to recover all remaining messages of each storage queue when first node startup and we can
        read remaining message concurrently of each storage queue. Default value to set here to 5. You can
        increase this value based on number of storage queues exist. Please use optimal value based on
        number of storage queues to speed up warm startup.
        -->
        <concurrentStorageQueueReads>5</concurrentStorageQueueReads>
        <!-- Virtual host sync interval seconds in for the Virtual host syncing Task which will
            sync the Virtual host details across the cluster -->
        <vHostSyncTaskInterval>900</vHostSyncTaskInterval>
        
        <!--
         Enables network partition detection ( and surrounding functionality, such
         as disconnecting subscriptions, enabling error based flow control if the
         minimal node count becomes less than configured value.
        -->
        <networkPartitionsDetection enabled = "false">
              
               <!--
                The minimum node count the cluster should maintain for this node to
                operate. if cluster size becomes less that configured value
                This node will not accept any incoming traffic ( and disconnect
                subscriptions) etc.
               -->
              <minimumClusterSize>1</minimumClusterSize>
        </networkPartitionsDetection>
    </recovery>
    <!--
        Specifies the deployment mode for the broker node (and cluster). Possible values {default, standalone}.
        default - Broker node will decide to run HA (master/slave) or fully distributed mode. Decision is taken based
                  on the node has a clustering mechanism enabled or not. If the node is not configured to join a cluster
                  it will run in HA mode (refer to axis2.xml for more information). If the node can join a cluster it
                  will start in fully clustered mode.
        standalone - This is the simplest mode a broker can be started. Node will assume datastore is not shared with
                     another node. Therefore it will not try to coordinate with other nodes (possibly non-existent) to
                     provide HA or clustering.
    -->
    <deployment>
        <mode>default</mode>
    </deployment>
</broker>

Click an element below for more information on that element.

<broker>

This is the top level element of the broker.xml file. It contains all the other elements needed to configure WSO2 MB.

<coordination>

This element contains configurations relating to the Apache Thrift communications. These configurations are important when MB is run in a clustered mode.

Configurable sub elements
Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<nodeID>In a clustered deployment, a ID is assigned to each MB node via the cluster node identifier. This element can be used to override the cluster node identifier for this MB node. If the value for this element is left as default, the default node ID is generated using the IP (Internet Protocol) and UUID).StringdefaultN/AMandatoryThe node ID of each member in a cluster should be unique.
<thriftServerHost>

Apache Thrift is embedded in WSO2 MB and is used for communications related to message delivery. In each MB node of a cluster, the value for this property (thrift server host) should be the IP address of that respective node.

Note: One of the nodes in an MB cluster will be used as the coordinating MB node at server startup. The Thrift server configured for the coordinating MB node will serve as the central Thrift server, which will be used by all nodes in the cluster to consume thrift services. The coordinating MB node may switch to another node in the cluster in case the current coordinator becomes unavailable.

StringlocalhostN/AMandatory
<thriftServerPort>This should point to the port of the Apache Thrift server in WSO2 MB.String7611N/AMandatory
<thriftServerReconnectTimeout>The number of seconds taken by the thrift server to reconnect after a time out.Integer5N/AMandatory
 <thriftSOTimeout>This is used to handle half-open TCP connections between the broker nodes in a cluster. In such situations, the socket may need to have a timeout value to invalidate the connection (in milliseconds). A timeout of zero is interpreted as an infinite timeout.Integer0N/AOptional

<transports>

This element contains all the messaging transports used by WSO2 MB. These messaging transports can be enabled/disabled as required. All the transports are enabled by default. This element also contains configuration parameters that enable you to customise the logical aspects of the message flows used within WSO2 MB.

Configurable sub elements

The following configurable sub elements are common to both AMQP and MQTT transports.

Element/Attribute NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<bindAddress>The IP address to which all transport listeners are bound (e.g. amqp and mqtt listeners).IntegerThe IP of the resident node
MandatoryThis is the address exposed from the server and not the host name inferred from carbon.xml.
<defaultConnection>This element is used to specify default values with regard to the connection of the transport. It contains the enabled and port attributes.




enabledIf the value is true, the relevant transport is enabled for WSO2 MB.Booleantruetrue/falseMandatory
portThe default listening port for messages/commands from the MB server via the relevant transport.Integer5672


<sslConnection>
This element is used to specify default values with regard to the SSL (Security Sockets Layer) connection of the transport. It contains the enabled and port attributes.




enabled
If the value is true, SSL is enabled for WSO2 MB.Booleantruetrue/falseMandatory
portThe default listening SSL port for messages/commands from the MB server via the relevant transport. This port is used only if the enabled attribute of the sslConnection element is set to true.Integer8672
Mandatory if SSL is enabled.
<keyStore>This element contains parameters relating to the keystore directory which include location and password. See the section on working with security for details on keystores.




<location>The path to the keystore directory. See the section on working with security for details on keystores.Stringrepository/resources/security/wso2carbon.jksrepository/resources/security/wso2carbon.jksMandatory
<password>The password for the key store.Stringwso2carbonwso2carbonMandatory
<trustStore>This element contains parameters relating to the truststore which include location and password.




<location>The location of the truststore.Stringrepository/resources/security/client-truststore.jks


<password>The password for the truststoreStringwso2carbon


The following configurable sub elements are specific to the AMQP transport.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<maximumRedeliveryAttempts>The maximum number of times the WSO2 MB should attempt to redeliver a message which has not reached a subscriber. For example, when the value for this is 10, ten more attempts will be made to deliver the message. The default value can be changed depending on your reliability requirements. See the topic on maximum delivery attempts for more information on this configuration.Integer10
Mandatory
<allowSharedTopicSubscriptions>If the value for this parameter is true, it is possible to have multiple durable subscriptions with the same subscription ID. As a result, when a topic is used, only one of the subscribers will get the given message based in a Round Robin manner.BooleanFalse


<allowStrictNameValidation>If this value is set to false, it is possible to use the colon (':') symbol in topic names. Note that this only applies when amqp is used.BooleanFalse


The following configurable sub elements are specific to the MQTT Transport.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<inboundBufferSize>The ring buffer size of the MQTT inbound event disruptor. Increasing this value would improve performance, but it would also increase the memory consumption.Integer32768


<deliveryBufferSize>The ring buffer size of the MQTT delivery event disruptor. As for <inboundBufferSize>, increasing this value would improve performance, but it would also increase the memory consumption.Integer32768


<security>This element contains parameters relating to authentication for the MQTT transport which include <authentication> and <authenticator>.




<authentication>

This parameter is used to specify whether clients should always send credentials when establishing a connection. Possible values are as follows.

Optional: If this is selected, credentials of the client are validated if they are sent and the connection is established if the credentials are valid. However, if no credentials are sent, the connection is established without performing a validation test. This behaviour adheres to MQTT 3.1 specification.

Required: If this is selected, the server always performs an authentication test before establishing a connection. The connection is rejected if no credentials are provided by the client or if the credentials sent are not valid.

BooleanOPTIONALYes

<authenticator>

The fully qualified class name of the authenticator. Class should be inherited from org.dna.mqtt.moquette.server.IAuthenticator.

Default implementation authenticates against the carbon user store based on the supplied username/password.

Stringorg.wso2.carbon.andes.authentication.andes.CarbonBasedMQTTAuthenticator
Yes

<persistence>

This element contains configuration parameters relating to data persistence.

Configurable sub elements
Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<messageStore>The class that is used to access an external RDBMS database to operate on messages.Stringorg.wso2.andes.store.jdbc.JDBCMessageStoreImpl


<contextStore>The class that is used to access an external RDBMS database to operate on server context. e.g. subscriptions.
org.wso2.andes.store.jdbc.JDBCAndesContextStoreImpl


<idGenerator>The ID generation class that is used to maintain unique IDs for each message that arrives at the server.
org.wso2.andes.server.cluster.coordination.TimeStampBasedMessageIdGenerator


<storeHealthCheckInterval>The length of the time interval between two checks made by the system to ensure that communication between the message store and the MB server instance is healthy.Integer10


<transaction>

This element contains configurations relating to publisher transactions.

Element NameDescriptionTypeDefaultFixedMandatory/OptionalNotes
<dbConnectionPoolSize>The number of connections reserved at a given time for transactional database tasks. A transaction reserves a database connection until the transaction is committed, rolled back or closed.Integer10


<maxBatchSizeInKB>The maximum number of kilo bytes included in a transaction. Exceeding this number will cause failure in commit requests.Integer10240


<maxWaitTimeout>Maximum wait time for a transaction to be successfully committed. If the transaction commit request is not completed within this time period, an error is thrown. Be sure to configure the wait time based on the speed of your database. If it takes longer than 30 seconds to respond you need to change the default value.Integer30


<performanceTuning>

This element contains configurations relating to the memory and processor allocations of the WSO2 MB server.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<slots>

Each subscriber is assigned a slot by WSO2 MB. The subscriber reads messages from this assigned slot. A slot comprises of a chunk of messages in a row.

This element contains all parameters relating to slots which include slotRetainTimeInMemory, windowSize.






<slotRetainTimeInMemory>The maximum time duration for which a slot can be retained in memory. Once the time specified in this parameter elapses, the messages in the slot are updated to the coordinator node in the cluster.Integer1000

The value is given in milliseconds.
<windowSize>
This parameter is used to specify a rough estimate for the size of the slot. e.g., If the size of the slot is 1000, it can expand to 3000 when there are 3 nodes.Integer1000


<windowCreationTimeout>This parameter defines the timeout for the slot window creation task. In a slow message publishing scenario, this parameter accounts for the delay in the delivery of each message. e.g., If one message is published per minute, then each message will be delivered only after they are submitted to the slot coordinator once this timeout has taken place.
3000


<delivery>This element contains all the parameters relating to message delivery which include maxNumberOfReadButUndeliveredMessages, ringBufferSize, parallelContentReaders, and parallelDeliveryHandlers.




<maxNumberOfReadButUndeliveredMessages>The maximum number of undelivered messages that can be stored in the memory. Increasing the value for this parameter can cause out-of-memory exceptions, but the performance will be improved.Integer1000


<ringBufferSize>The thread pool size of the queue delivery workers. This should be increased if there are a lot of unique queues in the system at a given time.Integer4096


<parallelContentReaders>The number of parallel readers used to read content from the message store. Increasing this value would increase the speed of the message sending mechanism. However, it would also cause the load on the data store to increase.Integer5


<parallelDeliveryHandlers>The number of parallel delivery handlers used to send messages to subscribers. Increasing this value will increase the speed of the message sending mechanism. However, it would also cause the load on the data store to increase.Integer5


<contentReadBatchSize>





<ackHandling>This element contains parameters relating to message acknowledgement which include maxUnackedMessages, ackHandlerBatchSize, and ackHandlerBatchSize.




<maxUnackedMessages>The maximum number of unacknowledged messages allowed. The message delivery from the server to the client is temporarily paused when the number specified for this parameter is reached. This number should be specified considering the message consumption rate.Integer1000


<ackHandlerBatchSize>The maximum batch size of the acknowledgement handler. Andes processes acknowledgements in batches using Disruptor. Increasing the batch size reduces the number of calls made to database by MB. The value for this parameter should be set based on database optimization. The maximum batch size is applicable in high throughput scenarios. Messages are handled in smaller batches using the Disruptor in low throughput scenarios.Integer100


<ackHandlerCount>The number of acknowledgement handlers used to process acknowledgements concurrently. Acknowledgements are batched and processed by these acknowledgement handlers.Integer5


<contentHandling>This element contains parameters relating to content handling which include contentChunkHandlerCount and maxContentChunkSize.




<contentChunkHandlerCount>The number of message chunk handlers used to process content chunks concurrently. The content chunks are batched and processed by these content chunk handlers. The value for this parameter should be set based on database optimization.Integer3


<maxContentChunkSize>The maximum column size for a content chuck handler.Integer65500


<inboundEvents>

This element contains parameters relating to the inbound events, which include parallelMessageWriters, bufferSize and messageWriterBatchSize.






<parallelMessageWriters>The number of parallel writers used to write content to the message store. Increasing this value will increase the speed of the message receiving mechanism. However, it would also cause the load on the data store to increase.Integer1


<bufferSize>The size of the Disruptor ring buffer for inbound event handling. Increasing the buffer size is recommended when there is an increased rate of publishing. In such situations, the messages can be stored in the memory.Integer65536

The buffer size should be an even number.
<messageWriterBatchSize>The maximum batch size of the batch write operation for inbound messages. MB internals use Disruptor to batch events. Hence this batch size is set to avoid database requests with a high load (i.e. with large batch sizes) to write messages. This should to be configured in high throughput messaging scenarios to regulate the load on the database from MB.Integer70


<purgedCountTimeout>The number of milliseconds to wait for a queue to complete a purge event in order to update the purge count. If the time specified here elapses before the queue completes the purge event, the purge count will not be updated to include the event. The value for this parameter can be increased to ensure that the purge count is accurate.Integer180


<transactionMessageWriters>The number of parallel writers used to write content to the message store for transaction based publishing. Increasing the value for this parameter reduces the time taken to commit a transaction, but the load on the data store would also increase.Integer1


<failover>This element contains parameters relating to failover which includes vHostSyncTaskInterval.




<messageCounter>This element contains parameters relating to the message counter which includes counterTaskInterval and countUpdateBatchSize.




<counterTaskInterval>Message counter tasks delay that occurs between the end of one execution and the start of another.Integer5

This value is specified in seconds.
<countUpdateBatchSize>The message count is updated in batches. Once the count exceeds the batch size, the message count update is moved to the Message Count Update task.Integer100


<messageDeletion>This element contains parameters relating to message deletion which include contentRemovalTaskInterval.




<contentRemovalTaskInterval>The task interval for the content removal task which will remove the actual message content from the store in the background. If the message rate is very high, this can be set to a lower value to minimise the number of delete requests per task.Integer3

This value is specified in seconds.
<topicMatching>

The method used for topic matching. If SIMPLE is selected, the default selector mechanism will be used. Alternatively, you can select BitMaps. BitMaps is more suitable when using topics and subscriptions in large quantity since it is faster.

BooleanSIMPLESIMPLE/BitMaps


<managementConsole>

This element contains parameters relating to the management console.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<messageBrowsePageSize>The maximum number of messages to be displayed in a page at a given time when viewing messages in a queue or the dead letter channel.Integer100


<maximumMessageDisplayLength>The maximum number of characters in a message that should be displayed in the Management Console when browsing queues. If the number of characters in a message exceeds the value specified for this parameter, the truncated message content will be displayed with the text message content too large to display. Increasing this value can cause delays when viewing the message content in the Management Console.Integer100000


<flowControl>

This element contains parameters relating to the message flow control.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<global>This element contains parameters which define buffer limits which enable/disable flow control at a global level which include lowLimit and highLimit.




<lowLimit>
The total number of message content chunks that would disable flow control if they are enabled, that should be stored in the buffer. Having a small difference between the lower and higher limits will lead to frequent enabling and disabling of flow control, causing the message publishing rate to be reduced.Integer800


<highLimit>
The total maximum number of message content chunks that should be stored in the buffer. When this limit is reached, flow control is enabled. Having a higher limit will increase the number of messages in memory before storing in DB. This results in a higher overall message publishing rate, but with reduced reliability.Integer8000


<bufferBased>This element contains parameters relating to the channel specific buffer limits which enable and disable the flow control locally which include lowLimit and highLimit.




<lowLimit>
The number of message content chunks that would disable flow control if they are enabled, that should be stored in the buffer. Having a small difference between the lower and higher limits will lead to frequent enabling and disabling of flow control, causing the message publishing rate to be reduced.Integer100


<highLimit>
The maximum number of message content chunks that should be stored in buffer per publisher. When this limit is reached, flow control is enabled for the relevant publisher. Having a higher limit will increase the number of messages in memory before storing in the DB. This would lead to higher message publishing rates, but with reduced reliability.Integer1000


<memoryBased>This element contains memory based parameters which include memoryCheckInterval, globalMemoryThresholdRatio, and globalMemoryRecoveryThresholdRatio.




<memoryCheckInterval>The time interval at which the server should check for memory consumption and apply flow control to recover.Integer2000


<globalMemoryThresholdRatio>

The maximum ratio of memory allowed to be used by the server.

Used Memory/Allocated Memory

Integer1.0

This is specified as a decimal between 0 and 1.
<globalMemoryRecoveryThresholdRatio>

The ratio at which the server should apply flow control to recover.

Used Memory/Allocated Memory

Integer1.0

This is specified as a decimal between 0 and 1.
<connectionBased>This element contains connection based parameters which include perConnectionMessageThreshold.




<perConnectionMessageThreshold>This allows you to apply flow control based on the message count on a given connection.Integer1000

Not used at present.

<recovery>

This element contains configurations relating to cluster recovery. Cluster recovery involves retrieving messages from a storage queues after the cluster or a single node has been inactive.

Element NameDescriptionTypeDefault ValueFixed ValuesMandatory/OptionalNotes
<concurrentStorageQueueReads>The number of storage queue reads carried out concurrently at a given time. There can be multiple storage queues operating before a cluster or a single node becomes inactive. The value for this parameter should be entered depending on the number of storage queues.Integer5


<vHostSyncTaskInterval>The time interval after which the virtual host syncing task can sync host details across the cluster.integer900

This value is specified in seconds.
  • No labels