For the record, Dispatch also uses this pattern to allocate a routable
address that exists for the lifetime of the Receiver/Link. This is
useful as a way to establish a receiver for replies to requests. The
assigned address can be used in the reply-to field of a request message
and the responses will find their way to the receiver link.
-Ted
On 10/04/2013 07:23 AM, Gordon Sim 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.
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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
