Given below are a list of tuning parameters:
For queue messages and durable topic messages
maxNumberOfUnackedMessages
| Parameter | <maxNumberOfUnackedMessages> |
|---|
| Attribute | Â |
| Description | This sets the flow control. When MB delivers messages to a particular subscriber, it keeps track of acknowledgements received from that subscriber (channel). If the subscriber fails to acknowledge fast enough, and if the unacknowledged message count exceeds this limit, MB will warn that it has no further room to receive messages. It will skip sending messages to that subscriber until acknowledgement is received for some of the messages already sent. |
| Example |
<maxNumberOfUnackedMessages>1000</maxNumberOfUnackedMessages>
|
maxNumberOfReadButUndeliveredMessages
| Parameter | <maxNumberOfReadButUndeliveredMessages> |
|---|
| Attribute | Â |
| Description | When delivering messages to subscribers, MB reads messages from the Cassandra server and keeps them in the memory, getting them ready to be sent. MB does not collect messages in the memory scheduling them to deliver if there are already enough messages scheduled in the queue.
Increasing this value will increase the message delivery speed if subscribers acknowledge faster. Consider the average size of a message when increasing this value because even if it is a small value, it can fill up the memory. |
| Example |
<maxNumberOfReadButUndeliveredMessages>1000</maxNumberOfReadButUndeliveredMessages>
|
messageBatchSizeForSubscribersQueues
| Parameter | <messageBatchSizeForSubscribersQueues> |
|---|
| Attribute | Â |
| Description | Not used (depreciated) |
| Example |
<messageBatchSizeForSubscribersQueues>20</messageBatchSizeForSubscribersQueues>
|
messageBatchSizeForSubscribers
| Parameter | <messageBatchSizeForSubscribers> |
|---|
| Attribute | <default> |
| Description | When messages are read into the memory to deliver to subscribers, MB will read messages from the Cassandra store. Within an iteration, the number of messages specified here (when the server starts) will be read from Cassandra by default. If MB manages to read the above given number of messages, it will then try to read 100 messages more from the store the next time it reads. If MB failed to read the above given number of messages, it will read 50 messages less in the next iteration. |
| Attribute | <max> |
| Description | In the above process, message reading from Cassandra will not exceed this number. |
| Attribute | <min> |
| Description | In the above process, MB will try to read a minimum of this number of messages. The message reading count will not go below this value. |
| Example |
<default>50</default>
<max>300</max>
<min>20</min>
|
globalQueueWorkerMessageBatchSize
| Parameter | <globalQueueWorkerMessageBatchSize> |
|---|
| Attribute | Â |
| Description | If you refer to the WSO2 MBÂ messaging architecture , MB keeps the incoming messages in a common pool and distributes them among nodes. While doing that, MB will read this many number of messages into the memory to distribute from the common message pool. MB will read only message metadata here so you don't need to consider the message size when changing this parameter. |
| Example |
<globalQueueWorkerMessageBatchSize>700</globalQueueWorkerMessageBatchSize>
|
messageBatchSizeForBrowserSubscriptions
| Parameter | <messageBatchSizeForBrowserSubscriptions> |
|---|
| Attribute | Â |
| Description | WSO2 Message Broker supports message browsing using JMS. When messages are browsed and there are a lot of messages in queues, it might not be necessary to browse all the messages. So the number of messages browseable can be limited using this parameter. |
| Example |
<messageBatchSizeForBrowserSubscriptions>200</messageBatchSizeForBrowserSubscriptions>
|
For both topic and queue messagesÂ
medataDatePublisherMessageBatchSize
| Parameter | <medataDatePublisherMessageBatchSize> |
|---|
| Attribute | Â |
| Description | WSO2 Message Broker supports message browsing using JMS. When messages are browsed and there are a lot of messages in queues, it might not be necessary to browse all the messages. So the number of messages browseable can be limited using this parameter. |
| Example |
<medataDatePublisherMessageBatchSize>200</medataDatePublisherMessageBatchSize>
|
contentPublisherMessageBatchSize
| Parameter | <contentPublisherMessageBatchSize> |
|---|
| Attribute | Â |
| Description | When messages are being published to the message broker, content is written to the Cassandra store. While this is done, messages are buffered in the memory. If the internal buffer reaches this size of messages, they are not flushed. Thus when a high TPS exists, you can control buffering via this configuration for incoming messages. If a high volume of messages are flushed to Cassandra at once, it might take some time to replicate the written data, or it might block outside Cassandra readers and writers while it is writing a lot of data at once (Cassandra read timeouts can happen as other threads concurrently read from Cassandra). Therefore, many factors along with Cassandra tuning, come into play. |
| Example |
<contentPublisherMessageBatchSize>200</contentPublisherMessageBatchSize>
|