Add a configurable limit for number of exchanges (backport #14304) #14339
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is like @SimonUnge's past work for vhosts and queues but for limiting the total number of exchanges.
Vhosts and queues are more expensive since they run processes while exchanges are just metadata. A limit would be good for exchanges too though, because if you create a really large number of them you can increase the memory footprint by quite a bit - through taking more space in the metadata store and making more work for monitoring. By default the limit is unset and it can be enabled with
cluster_exchange_limit = 100
or explicitly disabled withcluster_exchange_limit = infinity
, like the vhost limit.I've also added some small changes to the Khepri impls for
rabbit_db_exchange
'scount/0
andexists/1
so that we use the projection ETS table rather than a query, to make this as cheap as possible.This is an automatic backport of pull request #14304 done by Mergify.