Re: [amqp] Message groups

[Alan Conway <aconway@redhat.com>]

On Wed, May 29, 2019 at 5:05 AM Clemens Vasters <clemensv@microsoft.com> wrote:

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?

AFAIK our brokers work as follows: there's no special filter or marker on links. Any link that's eligible to receive a message may receive a group. When the first group message is sent on a link the broker "attaches" the group to that link. All future messages in the same group will be sent on that same link, as long as it stays attached. If the link detaches, the group is detached and can be attach to any other link. There's no way to "subscribe" to a group - any link may receive any group, but the group stays together. The association dies when the link detaches, soÂone link could take part of a group and detach, then the rest of the group can go to another link.

I think what you're describing works in both models, but without the need to explicitly set a filter in our case.

Â

Â