Partition Scaling

Partition scaling refers to adding partitions to or removing partitions from a partitioned queue. Partition scaling is triggered when the administrator changes the partition count of the queue.

When the partition count is decreased, the event broker removes extra partitions in the reverse order in which they were created (that is, the highest number partition is removed first). Any messages remaining in deleted partitions are also deleted.

When the partition count is increased, the event broker assigns each new partition the next highest partition number in the sequence.

Partition scaling triggers the Partition Rebalancing process on the event broker. The implications of Partition Handoff apply to partition scaling as well.

It may be preferable to move some messaging load to an alternate partitioned queue or to provision a new partitioned queue with more partitions, rather than changing the configuration of an existing partitioned queue.

Partition scaling is service affecting.

Adding and Removing Partitions

When the partition count changes, the key-to-partition mapping changes. The effect is that consumers are delivered a different set of messages than before. There is no easy way to shield consumers from this change.

Because of the impact to consumers, we recommend that you disable ingress to the partitioned queue to allow messages to drain from all existing partitions before changing the number of partitions.

The exact effect on the publishing application depends on the choice of the reject-msg-to-sender [including-when-shutdown] setting of the queue. If published message loss is unacceptable, you must enable this setting (including when the queue is shut down). The default for this attribute, as for all queues, is to enable reject-msg-to-sender (but not when the queue is shut down). Therefore, if the default is not changed, you can expect message loss when you follow the procedures below to change the partition count. For more information about this setting, see Configuring Message Discard Handling.

Changing the partition count has a significant impact on message delivery. The event broker does not maintain a history of key-to-partition mappings (the event broker calculates the mapping using a hash of the partition key). Because of this, when the partition count changes, subsequent messages with the same key will most likely be delivered to a different consumer, not because the partition-to-consumer mapping has changed, but because the key-to-partition mapping has changed.

When the partition count is increased, that new count comes into effect (key-to-partition mappings are recalculated) only after all the new partitions have been created.

If you change a queue from partitioned to non-partitioned or vice versa, the event broker unbinds all clients already bound to the queue. This ensures that the event broker and clients are consistently using (or not using) the semantics for partitioned queues. Note that any messages remaining in removed partitions are also removed.

If you change a queue from non-partitioned to partitioned, messages that are enqueued at the time of the change may get stuck because the event broker no longer delivers messages from the parent queue after the queue becomes partitioned. In this case, you can copy messages out of the parent queue.

Partition scaling is service affecting. Ensure that you follow the exact procedures provided below to add or remove partitions.

Adding Partitions

To add partitions (that is, to increase the partition count), do the following:

  1. Disable ingress for the queue. Egress (that is, delivery of messages to active consumers) continues for messages already in the queue.

  2. Wait for all outstanding messages from all partitions of the queue to be fully delivered.

  3. If the queue is replicated, wait for all messages on the DR-standby event broker to be acknowledged or consumed.

  4. Increase the partition count of the queue.

  5. Wait for the event broker to allocate new partitions and complete Partition Rebalancing.

  6. If the queue is replicated, wait for the DR-standby event broker to allocate its new partitions and complete the partition rebalancing process.

  7. Enable ingress for the queue.

Removing Partitions

To remove partitions (that is, to decrease the partition count), do the following:

  1. Disable ingress for the queue. Egress (that is, delivery of messages to active consumers) continues for messages already in the queue.

  2. Wait for all outstanding messages from all partitions of the queue to be fully delivered.

  3. If the queue is replicated, wait for all messages on the DR-standby event broker to be acknowledged or consumed.

  4. Decrease the partition count of the queue.

  5. Wait for the event broker to de-allocate extra partitions and complete Partition Rebalancing.

  6. If the queue is replicated, wait for the DR-standby event broker to de-allocate its extra partitions and complete the partition rebalancing process.

  7. Enable ingress for the queue.

Partition Scaling Status

A partitioned queue can have one of the following scaling statuses:

  • Ready—In this state, the queue has the expected number of partitions allocated.
  • ScalingUp—The queue has too few partitions. The next partition must be created. New partitions are not assigned to a flow until all new partitions have been created.
  • ScalingDown—The queue has too many partitions. The partition(s) created last must be deleted. The event broker immediately stops using the extra partitions (it unassigns them from their flows). Any messages in those partitions are lost.