You can configure how and when conflation is applied to different topics.
Conflation policies control how conflation is applied to a topic. You can set conflation policy for a topic with a
These are the available conflation policies:
- conflate (default)
"off" disables all conflation for the topic. Topic updates will never be merged or
"conflate" automatically conflates topic updates when back
pressure is detected by the server (that is, when the outgoing message queue exceeds
the maximum allowed size in bytes or number of messages).
"unsubscribe" automatically unsubscribes the topic when back
pressure is detected by the server, with a BACK_PRESSURE message.
The unsubscription is not persisted
to the cluster, so if a session fails over to a different server it will be
resubscribed to the topic. This policy is useful for topics
that are not essential to the application, and can be discarded in back
pressure situations without affecting the main function of the application.
"always" automatically conflates topic updates as they are
queued for the session. This policy ensures only the
latest update is queued for the topic, minimising the server memory and
network bandwidth used by the session, but potentially increasing the processor
cost of conflation.
If no policy is set, the "conflate" policy is applied.
The conflation process considers the value and delta updates in the queue, and the current
topic value (unless DONT_RETAIN_LAST_VALUE is enabled). It reduces the queued updates to a
single value or a composite delta, whichever requires the fewest bytes to send.
Under the default "conflate" policy, no conflation is applied until there is a new
message to send to a session with a full queue. The whole queue is then conflated, topic by topic. If conflation
is not enough to bring the queue size under the configured limit, the server will close the session.