Replies: 4 comments 4 replies
-
I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :( |
Beta Was this translation helpful? Give feedback.
-
I't s a bit difficult to suggest much since you haven't shared any specific steps that were taken. First I'd verify is that your exchanges are actually federated. This means they must be matched by a policy and the downstream side must open connections (links) to the upstream. If that does not happen, then the most likely reasons are
Federation links will be marked as such with an appropriate subscript "client type" on the connection page. Assuming that exchange federation links run and there is a message flow on the upstream side, the links should demonstrate |
Beta Was this translation helpful? Give feedback.
-
Here's what an exchange matched by a policy looks like on the downstream, together with a link displayed when On the upstream side, you can see a federation link as an inbound connection and a grayed out federated exchange on the exchange list: |
Beta Was this translation helpful? Give feedback.
-
Yeah, all of these are present in my setup. Not sure what else could be wrong |
Beta Was this translation helpful? Give feedback.
-
Hello,
I have two separate clusters and want to federate them to fanout messages from one cluster to another.
I did setup exchanges, policies, upstreams, but when I send a message from cluster1 -> cluster2 I don't see this message in demo queue on cluster2
Any suggestions?
Thank you
Beta Was this translation helpful? Give feedback.
All reactions