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 Wed, 09 Oct 2013 11:10:46 GMT
On 9 October 2013 11:24, Gordon Sim <gsim@redhat.com> wrote:

> On 10/08/2013 03:42 PM, Rob Godfrey wrote:
>
>> 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.
>>>
>> [...]
>
>  It would be great to have some convention that worked with different 1.0
>>> brokers.
>>>
>> [...]
>
>  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.
>>
>
> I was really just describing what qpid::messaging currently does when
> mentioning the create-on-demand capability. I should probably have left
> that to a footnote. I'm not that keen on this approach and it was really
> just an attempt to smooth the transition by supporting a 'legacy' feature.
>
>
>  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?
>>
>
> I personally much prefer the second approach. Its simpler and more
> flexible for broker implementers to do in different ways (according to
> their existing configuration mechanisms and details of the way their code
> already works). It also takes the 'decision' out of the client, which seems
> preferable from a 'philosophical' pint of view, and means that client
> libraries need not be affected.
>
>
But whether an attempt to send to/receive from an address which does not
exist should result in either a failure or the creation of a new node is
not just a broker/service concern - I'd actually think that it was an
application (and therefore client) concern.


> I'm certainly not suggesting any official 'standardisation'. I'm merely
> hoping to find a simple, practical, 'bottom-up' consensus that would make
> switching between AMQP brokers easier for users.
>
> If more brokers were to support some way of having nodes created on demand
> purely based on broker side configuration (the details of which would be
> broker specific), that would in my view be useful to anyone looking to try
> out applications against different brokers.
>
> As such, I'm keen to implement something like that in qpidd and would also
> be keen to start talking to some of the other broker maintainers to see if
> I could persuade others to do the same (if they have not already).
>
>
So while I don't object to brokers doing this, I'm really not keen on
trying to use names to identify the properties of nodes to be created and
furthermore trying to get some standardisation based on this - rather than
aiding interop this seems like something that will cause breakage when
people move from a broker that supports some naming pattern to one which
does not.  The idea of capability negotiation in AMQP is that this sort of
functionality van be requested and the absence of it easily detected with
an informative failure.  using naming patterns runs the risk of not having
informative failure as well as leading to contradictions between the
official standardisations in the fields of addressing and node behaviour,
and "unofficial" standardisations being promoted by individual projects.


>
>  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.
>>
>
> The two sentences above attempt to do that in a minimal way. To me they
> capture the essential capabilities that people expect when thinking of a
> queue or topic. I would of course be eager to here alternative suggestions,
> whether it be entirely different mechanisms, or just different capability
> names or descriptions. That's the purpose of the original email really.
>
>
So as above I'm pretty negative on just using names unless we can square it
with the work already ongoing in the global addressing work at OASIS and
the suggested work on standardising the expression of topic hierarchies /
subscriptions that is being mooted there at present.  Node properties are
the mechanism that were essentially designed for this purpose, it therefore
seems like we should use them.  If this is an issue for client libraries,
then maybe we can help those who have client libraries to enhance them.

I'm not suggesting that implementers should be prevented from defining
namespaces in which unknown addresses get auto created and based on the
name the created node would act as a queue or as a topic... but suggesting
this as a standard would likely cause more problems than it solves unless
the proposal is integrated into the existing OASIS work.


>
>   Obviously there exist a number of sub-behaviours also (like
>> the ability to support message priorities for instance).
>>
>
> Yes, but I wouldn't want to tie these all together. All the current 1.0
> brokers support the basic distinction between 'queue' and 'topic'. I'd like
> to get some consensus amongst the different communities around a way of
> recognising that. Two simple capabilities seemed like a good way to me, but
> I'm eager to hear other ideas.
>
>
(At present the most common approach is to use different conventions for
> the name/address of the node, e.g. topic://my-topic or /queues/my-queue
> etc).
>
>
>  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.
>>
>
> I wouldn't want to tie consensus on a very simple thing to a larger more
> comprehensive standardisation effort for management. Neither would I want
> to get in your way there however. If you have different names or
> descriptions that would align better with what you are doing, please feel
> free to suggest them.
>
>
But I wouldn't want to define a "simple" thing that (potentially) conflicts
with the work that is being done through the official standards, or gives
the impression of a standardisation which in fact is not standard.


>
>  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.
>>>
>> [...]
>
>  Where's [3]? :-)
>>
>
> Oops, forgot to add that or remove the reference. The point is simply that
> sometimes getting a 'node not found' error is a good thing as it highlights
> configuration errors simply and clearly rather than having processes 'talk
> past' each other.
>
>
>
Yeah - in fact this sort of problem is something that I often see with
users of the JMS 0-8 client when using BURL addresses - since it auto
creates the queues there is no error when a client has been misconfigured.

-- 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