GPrathap
8 years ago
parent
56ec6b1e96
commit
ffa6a9cf59
@ -1,482 +0,0 @@
|
|||||||
<?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>
|
|
||||||
<!--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>
|
|
||||||
</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>
|
|
||||||
</keyStore>
|
|
||||||
<trustStore>
|
|
||||||
<location>repository/resources/security/client-truststore.jks</location>
|
|
||||||
<password>wso2carbon</password>
|
|
||||||
</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>
|
|
||||||
</keyStore>
|
|
||||||
<trustStore>
|
|
||||||
<location>repository/resources/security/client-truststore.jks</location>
|
|
||||||
<password>wso2carbon</password>
|
|
||||||
</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>REQUIRED</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>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.extensions.device.mgt.mqtt.authorization.DeviceAccessBasedMQTTAuthorizer">
|
|
||||||
</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) for a transaction. Exceeding this limit will result
|
|
||||||
in a failure in the subsequent commit request. Default is set to 10MB. Limit is
|
|
||||||
calculated considering the payload of messages-->
|
|
||||||
<maxBatchSizeInBytes>10000000</maxBatchSizeInBytes>
|
|
||||||
</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>
|
|
||||||
<!--
|
|
||||||
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>
|
|
||||||
|
|
||||||
<!--Rough estimate for size of a slot-->
|
|
||||||
<windowSize>1000</windowSize>
|
|
||||||
|
|
||||||
<!-- 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.
|
|
||||||
-->
|
|
||||||
<timerPeriod>1000</timerPeriod>
|
|
||||||
|
|
||||||
<!--Number of SlotDeliveryWorker threads that should be started-->
|
|
||||||
<workerThreadCount>5</workerThreadCount>
|
|
||||||
|
|
||||||
</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>
|
|
||||||
|
|
||||||
</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>
|
|
||||||
|
|
||||||
</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>
|
|
||||||
|
|
||||||
<slotManagement>
|
|
||||||
<!--Set slot storage mode (RDBMS/HazelCast)-->
|
|
||||||
<storage>RDBMS</storage>
|
|
||||||
</slotManagement>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
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>
|
|
||||||
</recovery>
|
|
||||||
|
|
||||||
</broker>
|
|
||||||
Loading…
Reference in new issue