Gordon Sim wrote:
We're you able to get this working after registering?
I've had a nightmare week so I've just got round to this Gordon. It
seems to work fine and I appear to have successfully raised two Jiras :-)
The _purpose_ of 'federation' is to transfer messages between
different brokers; to create networks of brokers. Having a link from a
broker back to itself is a workaround for inadequacies of the internal
broker routing. I instinctively dislike this approach. It is probably
simply a matter of personal preference or taste. I see it as a likely
source of further problems.
However I'm not saying I would oppose a change that allowed the check
to be overridden, just that its not something I would use or recommend
myself.
I can see where you're coming from here, I guess that in my minds eye I
view federation more as a means to transfer messages between AMQP nodes
and I personally visualise a topology of exchanges/queues with brokers
forming part of the logical to physical mapping. It's probably a fair
point to argue that having a link from a broker to itself is a
workaround for inadequacies of the internal broker routing, but equally
if one visualises links as being between exchanges/queues and the broker
as part of logical -> physical one could argue that it makes sense to
employ similar mechanisms for inter and intra broker routing.
I'm curious as to how you'd cover the scenario I described previously
where I wanted one in bound link to fan out to both a processing
consumer and a headers exchange and have the processing consumer deliver
its results to the headers exchange. It seems so much more efficient to
do it on one broker, not to mention lifecycle management issues.
To be honest there seem to be other limitations on qpid-route, for
example IIRC you can only link exchanges with the same name via exchange
routes, which *sort of* makes sense though linking different types is
often useful, but I think that as it stands it wouldn't actually prevent
linking exchanges of different types if they happened to have the same
*name* on different brokers.
Sorry I'm probably sounding more critical than I mean to, email sucks
for nuances :-) I guess my point is that the broker and the QMF methods
support extremely flexible topologies (and rightly so IMHO) so it's just
a shame that the tool restricts this, 'cause there are some quite
imaginative ways of solving messaging problems out there.
The more I play with Qpid the more impressed I am, but conversely the
more annoying questions I seem to come up with. I really do appreciate
this mailing list and all the contributers :-D
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
