Given below are a list of tuning parameters related to WaitTimes:
Â
queueMsgDeliveryCurserResetTimeInterval
| Parameter | <queueMsgDeliveryCurserResetTimeInterval> |
|---|
| Description | When queue messages are delivered to subscriptions, MB resets the reading of messages from time to time (messages are ordered according to the arrival sequence)  in order to be fair with message distribution across subscriptions. This reset will happen every 50 read iterations automatically. When reset only, older messages which failed to get delivered are attempted to be delivered again. Set this value in milliseconds. |
| Example |
<queueMsgDeliveryCurserResetTimeInterval>60000</queueMsgDeliveryCurserResetTimeInterval>
|
maxAckWaitTimeForBatch
| Parameter | <maxAckWaitTimeForBatch> |
|---|
| Description | Maximum waiting time (in seconds) for an acknowledgement for a batch of messages that are sent from subscribers. Not used now. |
| Example |
<maxAckWaitTimeForBatch>120</maxAckWaitTimeForBatch>
|
queueWorkerInterval
| Parameter | <queueWorkerInterval> |
|---|
| Description | When delivering messages to subscribers, messages are read from the Cassandra store in iterations. If there are no messages to be read from Cassandra, reading will wait the above configured time before trying again. Also if there are no subscriptions to receive messages or reading messages seems to be getting late to process, or after every 10 reading iterations to give Cassandra a break, MB will wait the above configured time before going on to the next iteration. |
| Example |
<queueWorkerInterval>500</queueWorkerInterval>
|
pubSubMessageRemovalTaskInterval
| Parameter | <pubSubMessageRemovalTaskInterval> |
|---|
| Description | Messages for topics are removed automatically from Cassandra storage when eligible (determined by the <contentRemovalTimeDifference> parameter) after every above configured number of milliseconds. Consider the load on Cassandra when configuring this value. |
| Example |
<pubSubMessageRemovalTaskInterval>5000</pubSubMessageRemovalTaskInterval>
|
contentRemovalTaskInterval
| Parameter | <contentRemovalTaskInterval>
|
|---|
| Description | Messages for queues are removed automatically from Cassandra storage when eligible after every above configured number of milliseconds. Consider the load on Cassandra when configuring this value. In general, MB checks periodically and removes message metadata and content leisurely. |
| Example |
<contentRemovalTaskInterval>4000</contentRemovalTaskInterval>
|
contentRemovalTimeDifference
| Parameter | <contentRemovalTimeDifference>
|
|---|
| Description | Messages for topics are removed automatically from Cassandra storage when eligible. This eligibility is evaluated for all topic messages across clusters using the above configured time interval in milliseconds. Meaning, every topic message will be removed (irrespective of whether they were delivered or not) after the above configured time has elapsed after being published to the broker. This is not applicable for durable topic messages. |
| Example |
<contentRemovalTimeDifference>120000</contentRemovalTimeDifference>
|
topicPublisherTaskInterval
| Parameter | <topicPublisherTaskInterval>
|
|---|
| Description | Not used currently. |
| Example |
<topicPublisherTaskInterval>1000</topicPublisherTaskInterval>
|
virtualHostSyncTaskInterval
| Parameter | <virtualHostSyncTaskInterval>
|
|---|
| Description | When configured in clustered mode exchanges, queues, and bindings are synchronized across the cluster every above configured time interval in seconds. This task exists only to rectify any synchronization problems. |
| Example |
<virtualHostSyncTaskInterval>3600</virtualHostSyncTaskInterval>
|