On 12/09/2011 07:58 PM, Fraser Adams wrote:
Gordon Sim wrote:

I wouldn't consider these addressing examples as canonical reference
material! The Programming in Apache Qpid book is a bit of a mixture of
things. I'm not yet sure if or how these would fit in with that. In
the meantime I wanted to at least have somewhere where we could start
collecting 'recipes'.
I guess, though that book does contain a few address examples, but
they're a bit basic compared to your ones.

What's your thinking on how easy (or otherwise) the confluence wiki
stuff is to find from the main web site? As I said earlier I only found
these pages after you posted the link, it's not easy to find from the
main site.

I would agree that it is not well enough organised or easy to find things if you don't know they are there already.

I distinguish between on-demand creation of *shared* queues and/or
exchanges as addressable entities in their own right and the very
necessary on-demand (and hopefully increasingly transparent) creation
of 'subscription' queues as required by the AMQP 0-10 model.
I think I see what you're getting at here. I think that there are
subtleties though. In my case I have subscribers that may be considered
single "logical" entities, however in practice they may comprise several
physical instances each consuming messages from a given queue - in
effect the shared queue enables a fairly simple approach to scaling out
across multiple servers.

With regard to the former, my opinion is simply that it is worth
considering carefully whether it is required. If it is not, keeping
the configuration entirely separate from the clients has advantages
and static creation avoids any race conditions.
What sort of race conditions would you expect to crop up? I'm not aware
of seeing any issues with out

If you have multiple clients using the node, then the first to try and use it will create it. If there are any differences in node properties between these clients, then the properties used depend on who tries to use it first.

I certainly accept that having no durable record of queue
configuration (as distinct from having the messages on them persisted)
is an unfortunate limitation.
Are there any plans to introduce such a feature?

I don't know of anyone actively pursuing that as a priority at this point.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to