qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0 and creating nodes on the fly
Date Tue, 08 Oct 2013 14:42:00 GMT
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.
>
> 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
> brokers.
>
> 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.
>
>

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.

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?


> 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.  Obviously there exist a number of sub-behaviours also (like
the ability to support message priorities for instance).  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.



> 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.
>
> --Gordon
>
> [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.
>
>
Where's [3]? :-)

Cheers,
Rob


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message