qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [c++] Status of the AMQP 1.0 work
Date Sat, 06 Apr 2013 22:52:35 GMT
On 6 April 2013 08:40, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:

> Hi Gordon,
> 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

Having read the spec itself some time ago I haven't actually read many
comparisons that I could point you at I'm afraid. The key difference that
might help you better understand what Gordon outlined is that AMQP 1.0
focused more on P2P transfer of messages between nodes (e.g producer,
consumer, queue, something else) within containers (e.g client, broker, and
things that aren't either) and so doesn't define a broker model as 0-x did
or operations that which formed part of the support for that (e.g
queue-declare, exchange-declare etc).

> 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).
> 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??

I imagine what Gordon meant ties in to the above, in that because a broker
model and things such as explicit queue creation operations aren't part of
the core 1.0 protocol then many of the items currently going in x-bindings
for the 0-10 client won't necessarily apply to the 1.0 implementation in
the same sense.

1.0 deals with the transfer of messages between two nodes so the messaging
patterns available essentially boils down to what you do with that
functionality, such as mapping it to the broker model from the older
protocols or doing something entirely different. If the first node happened
to be a producer on a client and the second a queue or exchange on a
broker, then you can certainly do similar things to what we do now. Equally
you could do a lot of other things that for example don't involve clients
connecting to traditional brokers, and such interesting things are
certainly also being looked at (I'm sure people more involved with Proton
currently could chime in here on some of the things already being done
without brokers, such as Messenger to Messenger transfers).

As has been mentioned previously, one of the things being worked on by
members of the AMQP TC is outlining a management mechanism which can be
layered over the core protocol and used to provide operations on a
container (such as one acting as a broker).

> 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).
> 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"
> Actually that's got me thinking too there seems to be an inconsistency
> between qpid::messaging and JMS when it comes to selecting the protocol.
> With JMS it seems to be based on the Connection Factory, but with
> qpid::messaging you say "The protocol used is selected at runtime via the
> 'protocol' connection property" - I'm guessing that's set in the connection
> options map that gets passed to the Connection constructor? If analogous
> patterns were being followed then that would suggest that for JMS the
> protocol should be being selected via on of the options in the
> ConnectionURL, I guess in the brokerList? I know that you are primarily
> talking about C++ here, but you know me and bugbears about consistency and
> cohesion :-)
For various reasons, the 1.0 JMS client is entirely separate from the older
0-8/0-9/0-9-1/0-10 client so no amount of options will currently help it be
the similar to the C++ client in selecting its protocol, as it only has one

> One other thing, AMQP 1.0 support is derived from Proton, right? That
> doesn't seem to be the case for Java (at the moment at least) there seems
> to be amqp-1.0-client and amqp-1.0-client-jms in <qpid>/java in trunk.
> That's pretty confusing (well to me at least).
Correct. The simple reason why it is the way it is now is that proton-j
didn't exist until after that work was originally done, and some of the
people who would work toward such things were/still are working on fleshing
out proton-j itself. The intention is to end up with proton-j being used
for the client and broker 1.0 support.

The split between amqp-1.0-client and amqp-1.0-client-jms is just that JMS
layer is separated out and uses the underlying client code (and in turn,
common) from the other.


> On 05/04/13 11:27, Gordon Sim wrote:
>> Attached are some notes on the current status of the AMQP 1.0 support for
>> qpid::messaging and qpidd, describing how it is currently implemented and
>> highlighting some of the missing features and changes with respect to
>> addressing options. As ever, I am open to any feedback, questions,
>> criticisms or alternate opinions...
>> --Gordon.
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<users-unsubscribe@qpid.apache.org>
>> For additional commands, e-mail: users-help@qpid.apache.org

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