Hi Gordon,
These examples are great, however I have to admit that I find the
"cwiki.apache.org/confluence/" hard to find. It's only because I
bookmarked a link you previously sent on
https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP
that I ever made it there at all.
I think that my preference would be for these examples and the info on
the x-declare to be included in the Programming in Apache Qpid book,
which seems to be becoming somewhat of the canonical reference book.
What do you think?
If you're not keen on that then perhaps hyperlinks to the wiki pages?
if https://cwiki.apache.org/confluence/display/qpid/Index represents the
"real" Wiki "root" it might be better if that was what was linked off
the Qpid home page Wiki link rather than https://cwiki.apache.org/qpid/
if I'm honest I find it a bit confusing and it's not obvious which is
canonical.
Finally Re (from the addressing examples page) "Another use case for
more complex addresses is where shared queues are to be created on
demand, conforming to a specific configuration. My own advice is to
think carefully about whether this is needed in any given situation or
whether a static configuration might be more appropriate. However for
those who feel they require it,"
I've noticed you're views on this in some of your other posts on the
mailing list and I'm really curious as to your reasoning behind it.
My personal view is that I really like the idea of "self service"
subscription. In my particular scenario I've got producers delivering to
a headers exchange and acting kind of like a "data mart", where
consumers can come along and pick up subsets of data that they want.
I'm personally not especially "anti" administratively created queues
either (indeed I do this for setting up queue routes) however I think
it's a bit inconvenient for general subscribers. Also there are
currently general inconveniences with administratively created
queues/etc. (which would be nice to get sorted IMHO) in particular the
configuration doesn't persist broker restart. In other words if one
actually wants a non-durable queue (as in the messages aren't persisted)
you have to put up with it getting blatted when the broker restarts.
This is pretty annoying - especially for queue routes!!! you'll recall
some conversations we've had with respect to that.
Adding bindings administratively for lots of clients is fiddly too,
especially headers clients. In my scenario I've got dozens of consumers
with quite sophisticated headers bindings and when I need to restart the
broker the clients automatically reconnect and the queues & bindings get
recreated and the data just starts flowing. If I had to use
administratively created stuff yeah I could script it, but why is that
better than "on-demand" queues? Also I'd need to add some way to detect
the broker restart to cause my script to run - IMHO that all gets just a
bit messy. I'm already grumbling under my breath about the cron job I've
had to introduce to periodically attempt to re-create queues and links
from my source brokers in case they've restarted.
So I'm curious why you seem anti "on demand" creation and how you'd go
about managing a fairly large and complex environment via
administratively created queues/bindings given the sort of broker
restart scenario I describe above.
I look forward to your thoughts.
Cheers,
Frase
Gordon Sim wrote:
On 12/06/2011 07:46 PM, Fraser Adams wrote:
There's some useful docs for x-declare here
https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP
but it's quite hard to find and doesn't really illustrate that you still
need the "auto-delete:True" bit, which is possibly something you've
missed?
BTW I added a page on the wiki to collect some common example
addresses for different cases. Comments, suggestions improvements
always welcome!
https://cwiki.apache.org/confluence/display/qpid/Addressing+Examples
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
