ruby-amqp / hutch

A system for processing messages from RabbitMQ.
https://gocardless.com/blog/hutch-inter-service-communication-with-rabbitmq/
MIT License
857 stars 137 forks source link

Backward compatibility with old existing queues broken with introduction of queue types #348

Closed dsennerlov closed 4 years ago

dsennerlov commented 4 years ago

Problem

Existing queues, that where created with Hutch 0.27.0 have a queue_mode set to none, and the new default queue_mode implementation in Hutch makes it impossible to connect to these queues. Only way to set queue_mode to none is to not send the x-queue-mode argument.

Offending commit and lines

1f56c25 (#341)

Solution

This monkey patch will fix the problem:

module Hutch
  module Consumer
    module ClassMethods
      # MonkeyPatch get_arguments to keep backwards compatibility
      def get_arguments
        all_arguments = @arguments || {}
        all_arguments['x-queue-mode'] = @queue_mode if @queue_mode
        all_arguments['x-queue-type'] = @queue_type if @queue_type
        if @initial_group_size
          all_arguments['x-quorum-initial-group-size'] = @initial_group_size
        end
        all_arguments
      end
    end
  end
end

The fix is to add if @queue_mode and if @queue_type to have an option to not send the arguments.

This will allow me to set @queue_mode = nil and @queue_type = nil and get everything working.

michaelklishin commented 4 years ago

There is no such thing as "connecting to queues". Connections are not affected by the queue property equivalence requirement.

I cannot suggest anything without server logs or a traffic capture. As of https://github.com/rabbitmq/rabbitmq-common/issues/341 (RabbitMQ 3.8.2) a missing x-queue-mode is treated as the same as setting it to "classic".

If you have a set of steps to reproduce and a known solution, please submit a PR instead of recommending monkey patches.

michaelklishin commented 4 years ago

@dsennerlov can you please confirm that master works for your existing installation?

michaelklishin commented 4 years ago

This is the right moment to make any changes we want in this area as the next release will be a 1.0.0 (it's as good a time as any to ship it after several years worth of releases and production usage).

dsennerlov commented 4 years ago

@michaelklishin Confirmed, problem is solved in latest master.

michaelklishin commented 4 years ago

Thanks. I will produce a 1.0 most likely in the next 24 hours.