qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: A write up of some AMQP 1.0 Experiments
Date Mon, 03 Feb 2014 21:08:51 GMT
On 02/03/2014 07:53 PM, Fraser Adams wrote:
> On 03/02/14 15:38, Gordon Sim wrote:
>> They should be set for outgoing messages as of 0.24[1]. What version
>> were you using?
> I was actually using 0.27 off trunk built a couple of weeks ago.

Which properties didn't work for you using the x-amqp-* name?

>> The 0-10 to 1.0 conversion currently maps the 0-10 message-transfer's
>> 'destination' onto to the 'to' field. At the time I did it it seemed
>> logical enough, but I'm happy to remove that if it is confusing (as it
>> probably is).
> It's a difficult call, I personally suspect that it's potentially
> confusing. When I was trying this stuff out I wasn't sure if it was
> something that AMQP 0.10 qpid::messaging did or was an artefact of the
> mapping. It's probably safest to expect it to be explicitly added like
> it is on Messenger, might be worth a wider discussion though.

In translating from 0-10 to 1.0 it can't really be explicitly added, 
unless you mean as a special entry in the 0-10 application-properties? 
(On 1.0 the default is indeed to require iut to be explicitly set).

>> I added the incoming and outgoing link entities as they seemed to be
>> useful when thinking in terms of the 1.0 model. The source and target
>> are as they appear in the attach received.
> Yeah those seem to have potential, I stumbled across the "domain" and
> "incoming"/"outgoing" stuff I've not had a chance to play yet but the
> ability to establish links with arbitrary AMQP 1.0 containers seems
> really cool. Is this stuff ultimately intended to replace the
> "traditional" link/bridge federation model?

Listing the incoming and outgoing entities is useful even for a 
standalone broker. Creating them offers a mechanism similar to the 
links/bridges in 0-10.

>> * Reply-to
>> The qpid::messaging library doesn't particularly restrict the value of
>> the reply-to in the message itself[4].
>> If it can be interpreted as of the form <name>/<subject>, then the
>> address object returned will have both the name and subject set to the
>> respective substrings. Otherwise the name will contain the full reply-to.
>> If the application takes that address and uses it directly as an
>> address for creating a sender, the name is used as the source or
>> target address for the link and if a subject is specified it will be
>> used to set a filter.
>> I believe a common usage will have reply-to simply contain a node name
>> (often for a temporary queue). That pattern, essentially the
>> client-server example, works against several brokers and also the
>> dispatch router[5]. It is also familiar from JMS.
>> However if some other specific scheme/format is used, the application
>> would responsible for interpreting the address and e.g. establishing
>> separate connections etc if that behaviour is desired.
> I'll need to have more of a play with Reply-To but the thing I was
> really trying to get at was that given the peer to peer model of AMQP
> 1.0 it is (presumably) possible to set a Reply-To to the complete unique
> address of the sender (including host:port part) and the receiver could
> presumably directly address the sender without necessarily returning via
> intermediaries. That scenario seemed awkward for a connection oriented
> paradigm such as qpid::messaging or JMS because the host:port part might
> be an entirely different connection to the one it has used to connect to
> say a broker.

With qpid::messaging you can set a reply-to of almost any form on a 
message as well as getting it off a received message.

However passing the reply-to directly back to createReceiver() will 
result in an attach being sent for a receiver link with the source set 
to the node name in the address. It can't sensibly do anything else.

If you want to use other schemes, such as something that identifies a 
different process to connect to or whatever, then the application needs 
to handle the reply to according to whatever scheme is in use.

>> * Shared subscriptions
>> The 'shared' subscription capability is described in the AMQP 1.0 readme.
> Yeah I did notice it there, my problem was working out what the syntax I
> needed to use was.
>> Note that it is a qpidd specific extension. At present the
>> subscription queue will be autodeleted unless you set the link to be
>> durable or reliable.
> Ah I didn't realise that the reliable flag would help me. So would that
> be something like reliability:|||at-least-once| in the link properties?


> So are you saying that other AMQP 1.0 brokers generally don't support
> shared subscriptions? TBH that seems unfortunate I know that I find them
> incredibly useful to distribute workload between physical consumers.

They do likely support them, but they either won't expose that 
capability over AMQP 1.0 yet or they will do so in a different way (I 
haven't seen any other approach documented or I would have attempted to 
follow it).

>> Supporting an expiry policy of 'never' should be possible as well.
>> I'll update the test to note the convention around queue name.
> What I was getting at in that section of my post was "I couldn't see
> anything in the qpid::messaging code related to expiry" in other words
> there was no reference to pn_terminus_set_expiry_policy so (I think)
> it's additional code that's needed - have I missed something?

Right, there is no support as yet for controlling the expiration policy 
(right now link scope is assumed). Adding 'never' should not be difficult.

> So that's slightly worrying I hadn't clocked that. What I'm not clear
> about then is how I'd go about mapping the scenario I had with:
> x-bindings: [{exchange: 'amq.match', queue: 'testqueue', key: 'key1',
> arguments: {x-match: all, data-service: amqp-delivery, item-owner:
> fadams}}, {exchange: 'amq.match', queue: 'testqueue', key: 'key2',
> arguments: {x-match: all, data-service: http-delivery, item-owner:
> fadams}}]
> In this AMQP 0.10 case I've got two separate bindings added between
> amq.match and "testqueue" so messages will be delivered if either of
> them match.
> I (naively) thought that multiple filters was the way (though on
> reflection I can see that all filters must match - how else would my
> topic plus selector example work the way it did d'Oh).
> Can you think of a way how the use case I've suggested might be
> supported (aside from selectors - they are cool, but it'd be good to be
> able to replicate the legacy headers stuff completely - especially for
> migration/integration purposes).

Not really, I guess a new filter type of some kind would be one path. 
However I do think that using selectors is better and should work well 
even for migration/integration. You could have a headers filter that 
matched everything (e.g. just amq.match:any) and then specify the rest 
of the matching logic as a selector and your receiver would behave the 
same as if it had two headers bindings.

>> However we could probably look at ways to (optionally?) make this more
>> lenient. It certainly is also something that should be highlighted
>> more prominently in documentation somehow.
> It would be *really really good* to be able to make this more lenient
> (would quoted field names be a possibility e.g.
> 'data-service'='amqp-delivery')?

I've not looked at the parsing code, but I would think something like 
that should be possible and I agree that it would be useful since AMQP 
itself places no restrictions on property names.

>> I believe the selector filters are supported by a number of brokers
>> outside Qpid (ActiveMQ, HornetQ, SwiftMQ).
> That's useful to know, have you tried many interoperability scenarios?

I've successfully tried selectors against ActiveMQ. The only quirk is 
that it doesn't actually recognise the filters descriptor, but just 
recognises the filter name as used by the current qpid JMS over 1.0 
client. SO the selector shorthand doesn't work, but a fully specified 
filter will.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message