This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

When you work with topics, messages that are not acknowledged by subscriber clients can cause your MB server to go out of memory. The message delivery strategy configuration is introduced in WSO2 MB to control this issue. This configuration allows you to control how messages that accumulate in memory should be handled by the server. See the following topics for more details:

Understanding message delivery patterns in WSO2 MB

All messages published to MB are stored in a database, which makes them inherently persistent. The MB will then read the messages from the database and deliver them to the relevant subscribers. The way messages flow through MB to subscribers works differently for Queues and Topics.

Queues are typically used for storing messages until a subscriber connects to the MB and consumes them. Therefore, queue subscriptions are inherently durable.

Topics in WSO2 MB are typically used for realtime message brokering. That is, messages published to a topic are required to be delivered to all the active subscribers instantly (in realtime). Messages that are published to a topic while a subscriber is inactive will be handled according to the durability of the subscription as explained below.

Durability of topic subscriptions:

  • If the topic subscriber creates a non-durable subscription to the topic, the messages published to the topic while the subscriber is inactive will be lost.
  • If the topic subscriber creates a durable subscription, the subscriber will be able to recover all messages that were published to the topic while the subscriber was inactive.

Read more about the durability of topic subscriptions.

Message delivery pattern for non-durable topic subscriptions

When there are non-durable topic subscriptions for a topic, the messages are temporarily stored in memory of the MB server until all the subscribers acknowledge that the message is received. However, sometimes a subscriber can be late to acknowledge, which will cause messages to accumulate in memory. The following steps describes how this message flow works:

  1. Messages published to MB are first stored in the database.
  2. MB fetches the messages from the DB and dispatches them to all the subscriber clients instantly.
  3. MB maintains a list of the dispatched messages in memory as meta data until the messages are successfully received by all the clients.
  4. The messages that are successfully received will send an acknowledgement back to the MB.
  5. Messages that are acknowledged by all the subscribers are removed from the meta data in memory.
  6. The messages that are not acknowledged by the subscriber will be retained in memory until such acknowledgement is received.

It is important to note here that the messages are not dispatched to subscriber clients from the MB according to the rate at which the messages are consumed by the subscriber. For example, consider that MB dispatches 1000 messages per second to each subscriber: Subscriber A may be consuming messages at the rate of 500 messages per second, whereas subscriber B will consume all 1000 messages per second. In this scenario, 500 messages that are not acknowledged by subscriber A will always be accumulating in MB memory. If the number of unacknowledged messages increases beyond a certain point, the MB server could run out of memory. Therefore, when you work with topics, you can change the message delivery strategy to address this issue.

Changing the default message delivery strategy

Follow the steps given below.

  1. Open the broker.xml file from the <MB_HOME>/repository/conf directory.
  2. Locate the parameters defining the topic message delivery strategy:

    <topicMessageDeliveryStrategy>
    	<strategyName>DISCARD_NONE </strategyName>
    	<!-- If you choose DISCARD_ALLOWED topic message delivery strategy, we 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>60</deliveryTimeout>
    </topicMessageDeliveryStrategy>
  3. Update the <StategyName> parameter using one of the following values:

    • DISCARD_NONE: This is the default setting, which ensures that none of the messages are discarded from memory in MB. All the unacknowledged messages will be retained in memory of the MB.
    • DISCARD_ALLOWED: If you set this value, messages dispatched from the MB will be removed from memory without waiting for an acknowledgement from the subscriber clients.
    • SLOWEST_SUB_RATE: If you set this value, messages will be dispatched to subscriber clients at the rate of the slowest subscriber. For example, if subscriber A consumes messages at the rate of 500 messages per second and subscriber B consumes messages at a rate of 1000 messages per second, MB will always dispatch messages at the rate of 500 messages per second to both the subscribers.
  4. Update the <deliveryTimeout> parameter with time period in seconds that is allowed before MB removes any unacknowledged messages.

  • No labels