On 10/14/2011 11:27 AM, Fraser Adams wrote:
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.
Depends on what you mean.
Inter-broker routing is in my view by definition a different mechanism,
one that is primarily involved with transferring messages over the network.
On the other hand, the matching algorithms, the mechanisms for
determining which messages go where, are indeed the same in both cases
even as it is currently implemented. It's this part that I think is
lacking at present. The exchange types as defined by the AMQP specs
between 0-8 and 0-10 are to me at least rather clunky.
Chaining exchanges - i.e. creating bindings between them - is sometimes
proposed as a way around this. I'm not convinced. Using a mechanism
intended for remote transfer to achieve this seems even more 'wrong' to me.
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.
Always hard to know what's best with only a limited understanding of
the application. One option would simply be to have two separate
subscriptions to the fanout exchange and the headers exchange; would
that work?
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.
The qpid-route tool is not great, I agree. It's a classic case where a
prototype ends up being the
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
Thanks! I also appreciate all contributions. It's really important to
have people using the stuff point out where they feel the flaws are for
their use cases. Threads like this where different visions and solutions
are thrashed out are invaluable.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
