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?
Yes
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: [email protected]
For additional commands, e-mail: [email protected]
