[rabbitmq-discuss] Odd delay in federation exchanges being recognized

Wed Sep 5 19:27:47 BST 2012

Let me admit up front that this is a weird one, but I'll press ahead on the
chance there's something there.

I've got two brokers I'm using the federation plugin with. I create a
single exchange 'skytap' on each broker, and make the 'skytap' exchange on
the other broker its upstream.

I create the rabbitmq.config file dynamically before starting each broker.
Starting from a blank slate (blowing away the mnesia directory), I launch
the two nodes concurrently.

When I go to the Exchange tab in either broker, I see two Exchanges as
expected:

   - federation: skytap -> rabbit at mq2.skytap.com B
   - skytap

The type of the exchanges is x-federation-upstream and x-federation,
respectively. However, when first starting up, the type column is a red
color indicating a problem, and hovering over it, I get a message to the
effect of "unknown exchange type x-federation. Messages published to this
exchange won't work."

Now, here's the interesting thing: I*f I wait long enough (usually around
10-15 minutes) **and without doing anything, the error state eventually
goes away* and the Exchanges seem happy. This has happened at least three
times, so it doesn't seem like a random fluke or that I accidentally did
something.

Here's my config file, FWIW...

[
{rabbit, [{cluster_nodes, [rabbit at mq1]}, {disk_free_limit, 104857600}]},
{mnesia, [{debug, trace}]},
{rabbitmq_federation, [{exchanges, [[{type, "topic"}, {upstream_set,
"skytap_upstreams"}, {virtual_host, "/"}, {exchange, "skytap"}]]},
{upstream_sets, [{"skytap_upstreams", [[{connection, "upstream-mq2"},
{max_hops, 1}, {exchange, "skytap"}]]}]},
{connections, [{"upstream-mq2", [{host, "mq2"}, {port, 5672}]}]}]}
].

Again, I realize this sounds a bit wonky, but it's happened enough times to
make me not think I'm crazy.

Thanks,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120905/c0a4933d/attachment.htm>