Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 81.103.221.52 as permitted sender)
Message-ID: <515FD174.5070808@blueyonder.co.uk>
Date: Sat, 06 Apr 2013 08:40:36 +0100
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: [c++] Status of the AMQP 1.0 work
References: <515EA703.8010303@redhat.com>
In-Reply-To: <515EA703.8010303@redhat.com>
Content-Type: multipart/alternative;
 boundary="------------060505010808060900040903"

--------------060505010808060900040903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------060505010808060900040903--