A new local random exchange

[MarcialRosales]

Proposed Changes

This is a new exchange type which works like the random exchange but only selects from bound queues that are on the same local node as the publishing connection.

In scenarios where at least one queue per RabbitMQ node is bound this exchange provides high publishing availability with no additional network hops which also reduces publishing latency.

Use case scenario

In a RabbitMQ cluster of three nodes: A, B and C.

3 classic (v2) queues are declared, one on each node: q-A, q-B and q-C and they are all bound to the same instance of the rabbitmq_local_exchange type.

A message published to the exchange on node A will only be delivered to queue: a-A, a message published on node B will only be delivered to q-B and so on. This is enough to provide very high publishing availability at very low latency.

Consumers

The consuming side is somewhat more complex. Users need to ensure that there are consuming applications to cover all queues and that at least one consumer is connected to each node. This means there need to be at least one consuming connection per RabbitMQ node. In this instance we need at least 3 consuming applications: c-A, c-B and c-C each connected to their own RabbitMQ node and consuming from the queue declared on each node: c-A is connected to node A and consumes from q-A etc.

To provide more consumption availability each consumer could connect to all nodes and consume from all queues. If competing consumption isn't desired then the queues could use the single active consumer feature.

This pattern does push quite a bit of topological knowledge onto the consuming applications, for example they need to know which queues are running on which nodes so that they can ensure we don't accidentally introduce and additional network hop for consumer delivery. But once this is set up very low latency consumption at high availability is possible.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• [X ] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

TODO

• Move to core.
• Rename. to rabbitmq_local_random_exchange / x-local-random
• Disallow non classic queues to be bound in the validate_binding/2 callback.
• Only select a random local queue, do not fall back to selecting a random remote queue (as the code currently does)
• Reformat towards modern erlang style (4 space indents. no redundant whitespace / indentation).

[kjnilsson]

I am wondering about the current behaviour with this exchange. Currently if there are more than one locally bound queue it will select a random one and if there are no locally bound queues it will select a random one from the full set of queues. So in the latter case it is no longer "local".

The alternative behaviour would be that it will deliver to all locally bound queues and never to queues that are not locally bound.

Looking for thoughts on this.

[dumbbell]

If there are no locally bound queues, I would expect the message to be treated like an unroutable message. My reasoning is that avoiding inter-node traffic contributes to maintaining the low latency sold by this exchange. And there is "local" in the name, not "maybe_local". Or, there could be an argument to configure the behavior.

If there are many locally bound queues, I'm not sure. Perhaps the routing queue should be taken into account?

Unrelated to @kjnilsson questions, is there any value in providing this exchange as a plugin, as opposed to inside the broker?

[kjnilsson]

@dumbbell we had a chat in slack about this and it seems the consensus is it should be strictly local and if a fallback is needed then an alternative exchange should be configured.

[kjnilsson]

Unrelated to @kjnilsson questions, is there any value in providing this exchange as a plugin, as opposed to inside the broker?

Probably not but all non-standard exchange types are AFAIK plugins so it is just following suite.

[dumbbell]

@dumbbell we had a chat in slack about this and it seems the consensus is it should be strictly local and if a fallback is needed then an alternative exchange should be configured.

Ah ok, I didn't follow the discussion there, but apparently we reached the same conclusion :-) I updated my message above to give my reasoning about this.

Unrelated to @kjnilsson questions, is there any value in providing this exchange as a plugin, as opposed to inside the broker?

Probably not but all non-standard exchange types are AFAIK plugins so it is just following suite.

That's what I thought but maybe it's a good time to revisit this decision. I see no value in the plugin format here. However, I see plenty of issues:

• It's a burden for developers because we have to deal with the code split into multiple Erlang applications (painful when there is an API change affecting many modules).
• It's a burden for the build system too and we maintain two of them.
• And above all, it's a usability problem for users: they can't just declare the exchange and enjoy it, they need to enable a plugin first (or worse, they need to contact their local admin to do it for them).

We are not saving any resources by putting that in a plugin.

[kjnilsson]

maybe it's a good time to revisit this decision.

I'm up for this

[dcorbacho]

This will throw a badarg for quorum queues, as it is not an Erlang pid.

[lhoguin]

Should we make this NOT a plugin then, and if so where should be the module? In rabbit directly? Happy to do the change after there's some consensus.

[kjnilsson]

I think the TODO list of this PR is:

1. Move to core.
2. Rename. to rabbitmq_local_random_exchange / x-local-random
3. Disallow non classic queues to be bound in the validate_binding/2 callback.
4. Only select a random local queue, do not fall back to selecting a random remote queue (as the code currently does)
5. Reformat towards modern erlang style (4 space indents. no redundant whitespace / indentation).

[kjnilsson]

Replaced by #10091