qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject AMQP 1.0 and creating nodes on the fly
Date Fri, 04 Oct 2013 11:23:25 GMT
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.

The AMQP 1.0 specification has a 'dynamic' field defined for sources and 
targets used on attach, which if set causes the broker to create the 
node on demand. This works well for the intended case of 'temporary 
reply queues', but not where the application wants to choose the name[1].

At present the qpid::messaging library over 1.0 treats a node name of 
'#' as a request for a broker assigned temporary queue. If the name is 
not '#' and the create option is specified, it will request a qpidd 
specific capability, create-on-demand[2].

With ActiveMQ and ApolloMQ, when attaching to a node it is always 
created on demand. The configuration for it is determined by matching 
the name against a set of preconfigured rules (this part is similar to 
RabbitMQ 'policies').

It would be great to have some convention that worked with different 1.0 

Ultimately if a common management protocol emerges, it could address 
this as well as many other things of course. However I think for this 
specific and limited case there is benefit in seeking consensus on 
something simple in the short term.

Though I see some value in not creating nodes on demand in some 
cases[3], I like the ApolloMQ approach for those cases where the 
convenience of doing so outweighs disadvantages.

I propose adding some mechanism for configuring qpidd to support the 
same behaviour for specific portions of the node namespace. This would 
be something like the RabbitMQ policies, with the ability to define a 
create-on-demand property for a given policy. Nodes matching the pttern 
for that policy would then be created on demand and would have any other 
settings in the policy applied to them.

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.

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.


[1]  The specification explicitly prohibits the name of the 
source/target being sent if the dynamic flag is set. The node name is 
specified as being assigned by the broker. There is also a field for 
passing desired properties of the node and/or communicating back the 
actual properties. Sending the dynamic node properties if the dynamic 
flag is not set is also prohibited.

[2]  However if particular node properties have been requested it will 
also send those, which strictly speaking is in violation of the 
specification. In any case, having the configuration specified by the 
first link to attach is error prone. The qpid::messaging implementation 
does have the ability to assert that the actual properties match the 
requested ones to highlight any errors early, but again that requires 
sending the node properties even when the dynamic flag is not set.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message