qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <gordon.r....@gmail.com>
Subject Re: [c++] Status of the AMQP 1.0 work
Date Tue, 09 Apr 2013 18:07:21 GMT
On 6 April 2013 10:40, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:

> I'm afraid that I've not had time yet to begin my journey down the AMQP
> 1.0 path. I don't suppose that you can point me to a quick reference that
> points to the key differences? I'll take a look at the spec when I get a
> bit of time, but I'd quite like something quick and dirty to help bootstrap
> me.
> I skimmed through your document and I'm afraid that one thing gave me a
> bit of a panic:
> "
> The x-bindings property is not currently supported for AMQP 1.0 in
> nodes or links. This has really been a question of priorities rather
> than ruling out any mapping. Though I don't think a generic binding
> solution is appropriate for the 1.0 implementation, I'm eager to here
> of use cases that would be affected here and see how best to address
> them.
> "
> So you ask for use cases well I use the headers exchange almost
> exclusively in my operational system and my Addresses are of the form:
> string address = "testqueue; {create: receiver, node: {x-declare:
> {arguments: {'qpid.policy_type': ring, 'qpid.max_size': 500000000}},
> x-bindings: [{exchange: 'amq.match', queue: 'testqueue', key: 'data1',
> arguments: {x-match: all, data-service: amqp-delivery, item-owner:
> fadams}}]}}";
> The actual matches are a generally a degree more complex which is one of
> the reasons I use the headers exchange, but the basic gist is that I'm
> creating non exclusive queues on demand by a consumer (basically producers
> "fire and forget" to amq.match and consumers "self-service" subscribe to
> data that they are interested in based on its data signature). I generally
> use the policy_type and max_size too (usually 2GB queues in reality).

Does each consumer create its own queue? I actually think this will be both
simpler and more powerful over 1.0 as the plan is to allow you to subscribe
to an exchange (which you can already do) using a selector. The key then
(if I understand the usecase) would be to ensure that the subscrption had
the right lifecycle (i.e. you could reconnect to it without loss of
messages while disconnected),

I'm afraid that I don't really understand what you mean by "Though I don't
> think a generic binding
> solution is appropriate for the 1.0 implementation". Perhaps an AMQP 1.0
> guide for AMQP 0.10 users might help me there :-) From the little I've
> gathered AMQP 1.0 doesn't have the same distinction between exchanges and
> queues and those are both "nodes" in AMQP 1.0?? But I'd assume that the
> same messaging patterns are available?? From a previous post by Rob in a
> Java context he mentioned that it's possible to consume directly from an
> exchange in AMQP 1.0 but equally he said that in implementation terms this
> was done via a temporary queue - that sounds pretty analogous to how
> "exchange routes" in the C++ broker actually have queues created under the
> hood i.e. only "conceptually" consuming directly off an exchange and not
> "really" - actually I have big issues with not being able to control the
> size/policy/flow-control of temporary queues, one of the reasons I always
> use queue routes is because I need to control this stuff - but that's an
> aside here.
> One thing that's not clear from your write up is whether the x-bindings
> property you are talking about is in the messaging client, or whether it is
> the underlying x-bindings property that gets passed to the broker. I'm
> guessing the latter which would also affect AddressStrings created by JMS
> consumers and via QMF? (Although I use the C++ broker most of my consumers
> use JMS).

It is in the messaging client. The x-bindings (and x-declare, x-subscribe),
map directly to 0-10 commands. There is no analogous mechanism for
*generic* binding operations in 1.0 - i.e. the ability to bind almost
anything to anything, regardless of the node you are sending to or
receiving from. However when you 'subscribe' to an exchange node, the
broker can infer bindings from the link attachment, generally through the
specification of a filter. In your case it sounds like that might be the
applicable pattern over 1.0 and given the matching is based on examination
of headers it could even be a selector.

I've got lots of consumers and some reasonably complex match scenarios so I
> I have to have them modify their AddressStrings there's going to be a bit
> of integration pain. I suspect that there will be anyway - at the very
> least I guess the JMS "java.naming.factory.initial" is different - for AMQP
> 1.0 it looks like it's "org.apache.qpid.amqp_1_0.jms.**jndi.**
> PropertiesFileInitialContextFa**ctory"

One thing I should make clear is that 0-10 is not going away any time soon.
The intention is not to force anyone onto 1.0, but simply to make it
available (and indeed I hope eventually the default for new developments).
The x- options were always going to be quite 0-10 specific. In some places
they were unavoidable. I'm hoping that for 1.0, most cases can be met much
more simply and effectively. But again, I wouldn't want anyone to be
alarmed by my mail as 0-10 is unaffected and will continue to be fully

Also, I do want to get feedback exactly like this. Highlighting things that
concerns existing users, especially if they would like to move to 1.0. I
can't guarantee 100% fidelity for all 0-10 address string options (some
simply cannot be sensibly mapped and would in any case tie you to qpidd so
tightly that there would be little benefit to using 1.0!). I do however
want to do what I can to ease the transition. So if I need to do some more
thinking on x-bindings, I'm happy to do that. Thanks for he feedback, its
very helpful!

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