qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: AMQP 1.0 and creating nodes on the fly
Date Wed, 09 Oct 2013 09:24:06 GMT
On 10/08/2013 03:42 PM, Rob Godfrey wrote:
> On 4 October 2013 13:23, Gordon Sim <gsim@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 

> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message