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.
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?? 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.PropertiesFileInitialContextFactory"
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 :-)
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).
Frase
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: [email protected]
For additional commands, e-mail: [email protected]
