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.
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.
--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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
