In Solace messaging, flow control is critical to ensure guaranteed delivery and efficient client-broker interaction. This post breaks down how flow is managed at both the broker and client API levels. Let’s first start with some core concepts.
Core Concepts
Solace Queue Unacknowledged Messages Limit
-
A broker-side setting that defines how many messages can be delivered to a client before they must be settled (acknowledged with ACK, NACK-REJECT, or NACK-FAILURE).
-
Example: if the limit is set to 5, the broker delivers only messages 1–5 to the client. Messages 6–10 remain queued until some of the earlier ones are settled.
Subscriber Window Size
-
A client-side mechanism, similar to TCP’s sliding window protocol.
-
The client tells the broker how many messages it can accept at once. If the window is 3, the broker delivers only 3 messages and then waits until the client signals that it can accept more.
How they work together?
-
The queue unacknowledged limit and subscriber window size operate independently.
-
The unacknowledged limit can be much larger than the window size. This means multiple messages can remain unsettled even as the window is being actively refilled.
-
Client APIs usually try to keep the window open, unless:
-
the application explicitly pauses flow (e.g., calling
stop()), or -
synchronous
receive()calls cause the internal queue to fill up.
-
-
By default, the internal API queue is sized to match the subscriber window size (with some exceptions, e.g., JCSMP uses window+1).
Flow Control Mechanics
-
The subscriber window size can grow or shrink dynamically throughout the session.
-
Each time the client consumes messages from its internal queue, the broker refills the window with more.
-
Flow control messages must be exchanged within a 30-second timeout. However, the client doesn’t need to resend control updates if the state hasn’t changed.
Ordered Processing Considerations
-
For strict ordering, one option is to set both the unacknowledged limit and subscriber window size to 1. This ensures single-message processing but comes at a big performance cost.
-
More commonly, defaults are used with application-level logic to enforce order (e.g., blocking APIs or synchronized callbacks).
-
Messages are always delivered to the client in queue order, but acknowledgments may happen out of order if the application processes them asynchronously.
In short: the broker limits outstanding unacknowledged messages, the client controls how many it can handle at a time, and together they ensure both reliability and performance.