On 10/08/2013 03:42 PM, Rob Godfrey wrote:
On 4 October 2013 13:23, Gordon Sim <g...@redhat.com> wrote:
A common convenience is to allow queues or topics to be created on demand,
i.e. having them come into existence when a link is attached. This is
useful where the messaging infrastructure is supposed to be a 'hidden' part
of the system, and manual configuration is not desirable.
[...]
It would be great to have some convention that worked with different 1.0
brokers.
[...]
So - there seem to be two different things here. One is the notion of an
AMQP property/capability for "create-on-demand" that AMQP "server"
containers might implement such that if they see a link attach to an
address which does not exist, and the given node property is specified,
then the server will (subject to any authorisation rules) create the node.
I was really just describing what qpid::messaging currently does when
mentioning the create-on-demand capability. I should probably have left
that to a footnote. I'm not that keen on this approach and it was really
just an attempt to smooth the transition by supporting a 'legacy' feature.
This idea seems like something we should propose and register and then
attempt to standardise in the OASIS AMQP specifications.
The second case of defining some namespace pattern within the broker
wherein any unrecognized names will lead to node creation seems like a
broker specific feature with no need (or requirement?) for standardisation.
Am I missing something here?
I personally much prefer the second approach. Its simpler and more
flexible for broker implementers to do in different ways (according to
their existing configuration mechanisms and details of the way their
code already works). It also takes the 'decision' out of the client,
which seems preferable from a 'philosophical' pint of view, and means
that client libraries need not be affected.
I'm certainly not suggesting any official 'standardisation'. I'm merely
hoping to find a simple, practical, 'bottom-up' consensus that would
make switching between AMQP brokers easier for users.
If more brokers were to support some way of having nodes created on
demand purely based on broker side configuration (the details of which
would be broker specific), that would in my view be useful to anyone
looking to try out applications against different brokers.
As such, I'm keen to implement something like that in qpidd and would
also be keen to start talking to some of the other broker maintainers to
see if I could persuade others to do the same (if they have not already).
One other aspect of this that is important is how to determine if the node
should be a 'queue' or a 'topic', as the two most common node types. One
suggestion would be to have brokers recognise two specific capabilities for
these types. The 'queue' capability implies the ability to distribute
messages between consumers in some fashion, and to store messages when no
consumers are available. The 'topic' capability would distribute all
messages to all subscribers (i.e. non-competing consumers) and would drop
messages if there were no subscribers.
Yes, we need to define what node-properties terms like "queue" and "topic"
actually mean.
The two sentences above attempt to do that in a minimal way. To me they
capture the essential capabilities that people expect when thinking of a
queue or topic. I would of course be eager to here alternative
suggestions, whether it be entirely different mechanisms, or just
different capability names or descriptions. That's the purpose of the
original email really.
Obviously there exist a number of sub-behaviours also (like
the ability to support message priorities for instance).
Yes, but I wouldn't want to tie these all together. All the current 1.0
brokers support the basic distinction between 'queue' and 'topic'. I'd
like to get some consensus amongst the different communities around a
way of recognising that. Two simple capabilities seemed like a good way
to me, but I'm eager to hear other ideas.
(At present the most common approach is to use different conventions for
the name/address of the node, e.g. topic://my-topic or /queues/my-queue
etc).
This definitely
overlaps with management as we would want to have some commonality between
names used in node properties and the names used for creation of nodes
through the management spec.
I wouldn't want to tie consensus on a very simple thing to a larger more
comprehensive standardisation effort for management. Neither would I
want to get in your way there however. If you have different names or
descriptions that would align better with what you are doing, please
feel free to suggest them.
Any thoughts, comments, complaints, alternative suggestions etc? I'd like
to get agreement on something that is simple but useful for users and not
difficult for different brokers to implement to improve the chances of a
de-facto standard emerging.
[...]
Where's [3]? :-)
Oops, forgot to add that or remove the reference. The point is simply
that sometimes getting a 'node not found' error is a good thing as it
highlights configuration errors simply and clearly rather than having
processes 'talk past' each other.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
