max_hops parameter appears to be ignored when working with multiple virtual hosts

[surfkansas]

The rabbitmq-federation plugin appears to have a bug with multi-hop federation. When trying to set up federation on a single node with multiple v-hosts, the max_hops property appears to be ignored.

The attempted setup is described here with max_hops > 1 https://www.rabbitmq.com/federated-exchanges.html

Setup commands for this test are:

  sudo rabbitmq-plugins enable rabbitmq_federation && \
  sudo rabbitmq-plugins enable rabbitmq_federation_management      
  sudo rabbitmqctl add_user dude surfer && \
  sudo rabbitmqctl set_user_tags dude administrator && \
  sudo rabbitmqctl add_vhost first && \
  sudo rabbitmqctl add_vhost second && \
  sudo rabbitmqctl add_vhost third && \
  sudo rabbitmqctl set_permissions -p first dude ".*" ".*" ".*" && \
  sudo rabbitmqctl set_permissions -p second dude ".*" ".*" ".*" && \
  sudo rabbitmqctl set_permissions -p third dude ".*" ".*" ".*" && \
  sudo rabbitmqctl set_parameter -p second federation-upstream from-first '{"uri":"amqp://dude:surfer@localhost/first","max-hops":3}' && \
  sudo rabbitmqctl set_parameter -p third federation-upstream from-second '{"uri":"amqp://dude:surfer@localhost/second","max-hops":3}' && \
  sudo rabbitmqctl set_policy -p second federate-me ^amq. '{"federation-upstream-set":"all"}' && \
  sudo rabbitmqctl set_policy -p third federate-me ^amq. '{"federation-upstream-set":"all"}'

Upon setting up this environment and verifying that upstream status are working, we then create queues on the different environments and bind to the amq.fanout exchange.

When sending a message to the amq.fanout on first, it will be propagated to the amq.fanout exchange on second. All queues bound to either of these fanout exchanges will receive their messages. However, queues bound to amq.fanout on third will not receive messages.

If the message is sent to amq.fanout on second, both second and third receive messages.

The expected behavior would be that messages sent to first would propagate both to second and third, as the federation upstream is setup with max-hops equal to 3.

When setting this same design up across three nodes (and not with three virtual hosts), the expected behavior works perfectly.

As such, one of two changes should occur:

• rabbitmq-federation plugin be modified to allow two-hop federation to work with virtual hosts or
• documentation be added that two-hop federation is NOT expected to work with virtual hosts

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).

We get at least a dozen of questions through various venues every single day, often light on details. At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because GitHub is a tool our team uses heavily nearly every day, the signal/noise ratio of issues is something we care about a lot.

Please post this to rabbitmq-users.

Thank you.

[michaelklishin]

Connections to virtual hosts within a node are no different to federation than connections to remote nodes. Thanks for the upstream and policy examples, please also provide a runnable example of the topology on the mailing list and explain what the end goal is.