Message groups

The spec we discussed late in the F2F and which is required for breaking up ultra-large HTTP messages is the grouping spec.

What we do in Service Bus today is to create link with a special group filter that holds the id of the group that the link shall be dedicated to. If the group filter value is null, the source chooses an available group, assigns it, and fills in the filter.

Using the group filter changes the behavior of a queue or a shared topic subscription insofar that all messages with a matching group-id will be exclusively assigned to that link, and each group effectively maintains its own cursor through the log (next delivery candidate is the oldest available message for the group), meaning that groups demultiplex the queue. We require customers to turn on support for groups with a feature flag.

Creating a link with a filter for a group-id that has already an exclusive owner will fail – but we put a vendor-specific timeout property on ‘attach’ that allows the source to hang around and wait responding to ‘attach’ until it can acquire the group assignment. A group assignment can be acquired if there is at least one message with the given group-id is instantly available for delivery and if that group-id is not yet assigned. Once that pending message has been delivered, the link waits for further messages of that group.

In our model, groups are generally unbounded and you can hang on to the link until the app decides its done with the group. In the broker, we effectively ignore the group-sequence-id and leave interpretation to the app as an producer-controller end-to-end ordering hint.

For HTTP-over-AMQP where we ought to expect many small and just a few very large messages, I can imagine a modification of this model which allows the source to dynamically assign groups to existing links. Here, a link would attach with a filter that expresses that the receiver wants dynamic group assignments and whether the link is also eligible for messages that are not part of any group.

The receiver would then get regular messages and messages associated with groups intermixed, and for any messages that are part of groups, it would be assured that competing consumers never get to steal messages from that group. The association sticks with the terminus once made, but a terminus implementation might forget them after some inactivity period just like dedupe filters have some capacity or age limits.

Thoughts?

amqp message