[rabbitmq-discuss] federation Issues

[Ganann, Kale]

Update - we renamed the cluster to something meaningful and deleted all the dynamic objects so there were absolutely no artifacts left over.  We've got three vHosts with queues bound to e.fed.topic and the same routing key.  If I publish to the e.fed.topic on fed with that key, all three get it.  If I publish on vHost a, vHost b sometimes gets it, but not everytime, vHost c does not.  Similarly, we can publish to b, and sometimes a gets it, c does not.  Nothing published to c shows up anywhere else.

Thanks,
Kale


-----Original Message-----
From: rabbitmq-discuss [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Ganann, Kale
Sent: Friday, June 27, 2014 9:11 AM
To: 'Simon MacMullen'; Legacy list about RabbitMQ
Subject: Re: [rabbitmq-discuss] federation Issues

To your first question:

In production, federation links (specifically, x-federation-upstream under exchnages) show as: vHost | federation: e.fed.topic -> sharedfederationid:fed:e.fed.topic B, for example.  The sharedfederationid is used in the old parameters section as an explicit identity for a local user, hence, a user token.  I believe below you're calling this local_username, sorry for the confusion.  The dynamically created queues look much the same.

Now in dev, where we did the upgrade, a similar link would show as: vHost | federation: e.fed.topic -> ClusterName:fed:e.fed.topic B.  From what you're saying below, this is due to the change in the authentication manner - the local_username no longer need be applied.  There were some artifacts of the old federation style links, and when we've had fed problems in the past, they were resolved by deleting the x-federation-upstreams in fed and the affected vHost, as well as the related queues.  On deleting the dynamic queues, they would recreate and recreate the x-federation-upstreams, and everything would work.  That isn't happening this time.  If I publish to the e.fed.topic exchange in one vHost, it should publish to the queues in other vHosts that are bound to e.fed.topic with the same routing key, but right now the messages are vanishing - I'm having no luck tracing them.

All link statuses are Running.  Fed has an upstream to each vHost, and each vHost has an upstream to fed.

If I change the cluster name, will I have to delete all the dynamic streams again to get them to use the new name?

Thanks,
Kale


-----Original Message-----
From: Simon MacMullen [mailto:simon at rabbitmq.com]
Sent: Friday, June 27, 2014 6:11 AM
To: Legacy list about RabbitMQ; Ganann, Kale
Subject: Re: [rabbitmq-discuss] federation Issues

On 27/06/14 00:27, Ganann, Kale wrote:
> We just upgraded from 3.2.1 to 3.3.4 and federation died on us.  
> Looking at the cluster, it appears some... overenthusiastic dev 
> renamed the cluster

That should not be a problem.

 From 3.2.x to 3.3.x we changed from having the federation plugin give the cluster a name through the local_nodename parameter, to having a broker-wide cluster name that can be used by the federation plugin.

But the cluster name doesn't matter that much. It's used to name the queues which federation uses internally, and it shows up in transmitted bindings and messages so the plugin (and sysadmins) know where message have been. But it's not something you should have to get "correct" for things to work - there's no correct value.

> and now when federation creates new linkages, it creates them as 
> clustername:vHost:queue, rather than usertoken:vHost:queue.

I really do not understand any of this.

What do you mean by "linkages"? Bindings? Federation links (as shown in the status)? Something else?

Also, what do you mean by usertoken?

> Also, on
> the federation upstreams, the parameter field seems to have vanished, 
> so I can't update the user tokens for specific vHosts.

I guess you are saying something about the local_username or local_nodename fields here? local_username is gone, there is no need to configure it at all any more. local_nodename is replaced by the cluster name.

> I've been going
> through the patch notes - is this intentional, or is something else 
> going on?

The removal of local_username and local_nodename was intentional.

> And can I just remove the cluster name?

Clusters always have a name.

>  I've tried deleting
> the old dynamically created fed stuff so that it gets recreated, but 
> the new stuff just doesn't seem to work.  Any help is appreciated.

What does the link status look like?

Cheers, Simon

--
Simon MacMullen
RabbitMQ, Pivotal
This communication contains information that is confidential, proprietary in nature, and may also be attorney-client privileged and/or work product privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by replying to this message and delete this email immediately. Thank you for your cooperation. 

Please be advised that neither Altegrity, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.

_______________________________________________
rabbitmq-discuss mailing list has moved to https://groups.google.com/forum/#!forum/rabbitmq-users,
please subscribe to the new list!

rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss