qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: AMQP 1.0 and creating nodes on the fly
Date Tue, 08 Oct 2013 13:37:49 GMT
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.


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

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

View raw message