search

Particular / NServiceBus.RabbitMQ

RabbitMQ transport for NServiceBus
https://docs.particular.net/nservicebus/rabbitmq/
Other
88 stars 60 forks source link

Suppress creation of `nsb.v2.verify-stream-flag-enabled` queue #1272

Closed ramonsmits closed 1 year ago

ramonsmits commented 1 year ago

Describe the feature.

The nsb.v2.verify-stream-flag-enabled gets created by NServiceBus to probe for broker features.

A method to not have this created is needed to keep the queues in the broker clean.

If this gets added this option should also be available in ServiceControl via any of RabbitMQ's transport customizations

Additional Context

The problem is needed to check if the broker supports the stream features which is required by the v2 delayed delivery infrastructure introduced in v7 of the transport:

It is highly recommended to migrate delayed messages from the v1 to v2 delayed delivery infrastructure:

More information about the delayed delivery infrastructure:

bording commented 1 year ago

This cannot be suppressed. It's required to verify that the version of the broker the transport is running against can actually be used.

ramonsmits commented 1 year ago

Some more context:

  1. The streams feature is implicitly used by the NServiceBus RabbitMQ delayed delivery infrastructure.
  2. Not having the streams feature enabled on the RabbitMQ broker results in unreliable at most once delayed delivery.
  3. The transport creates the streams queue to test if the broker has the streams feature enabled.
  4. The transport does not delete this queue to prevent issues with multiple instances creating/deleting this queue.
  5. Creating/deleting a queue is expensive. Having this idle queue might not be pretty but it is a lean method. When an instance tries to create an existing queue it basically behaves as a NOOP.
  6. Eventually the streams feature will be enabled by default on the broker. The transport could eventually require that minimum version so it doesn't have to create this test stream queue.
  7. While we could add a code API to not probe for this feature we will not do this simply because don't want any customer to accidentally lose messages. Such API calls are easy to add for testing and then accidentally remain there forever.