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 Thu, 06 Feb 2014 11:10:35 GMT
On 02/04/2014 07:56 PM, Fraser Adams wrote:
> On 03/02/14 21:08, Gordon Sim wrote:
>> 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.
> Yeah I can see why listing the incoming/outgoing entities would be
> useful for a standalone broker - presumably being able to navigate from
> a subscription queue to a link would enable me to see say the
> filters/selectors and other properties of the link (I'd be really nice
> to be able to see what filters/selectors were present).
> But my question was more about technical direction, as I say for AMQP
> 1.0 systems is this ultimately intended to become the primary way to
> enable federation?

I think dispatch router likely has a big part to play in federating 1.0 
systems, but I need to spend more time thinking about how that might 
work. What exists in the broker at present is merely the ability to hook 
the broker up to other things. I.e. I see it as a small part of the 
overall solution.

>> 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.
> So if I'm interpreting you correctly here; if say I'm a sender on
> localhost on port 5673 I might want to set a fully qualified reply to
> AMQP address of say:
> amqp://localhost:5673/response
> Now a consumer could in theory happily send a response directly to that
> address because of the peer to peer nature of AMQP 1.0, but I think what
> you are saying is that in qpid::messaging if such a ReplyTo was send
> there is no automagic mechanism given such an Address that if you pass
> it to createReceiver() it will cleverly create a Connection/Session.

Right, I think it would be bad for the messaging implementation to do 
that under the createReceiver() call. I think that with an API like 
qpid::messaging, it is the applications responsibility (and right) to 
control the creation of connections.

More commonly the receiver of such a message would call createSender() 
(in order to send a reply), and what would be acceptable there would be 
to send the reply back to the broker, over the existing connection, but 
using the reply-to address exactly as specified. That is indeed what 
will happen for something like 'amqp://my-host:5672/abc'. However at 
present the Qpid c++ broker won't recognise that address and so will not 
accept the link. The c++ broker does have support for relaying a message 
to another entity based on address, provided it has been configured to 
know how to connect to the entity (through creation of an appropriate 
domain), but doesn't yet recognise the form above. That would not be a 
difficult change however.

> So what you'd have to do would be to parse the
> ReplyTo to see if it had an amqp://<host>:<port> part and if it did
> create the necessary connection/session stuff and use the node name part
> for the actual qpid::messaging Address.


> So that makes some level of sense, but that's what I was meaning when I
> said that this scenario (which seems quite reasonable given the peer to
> peer nature of AMQP 1.0) was slightly *awkward* for connection oriented
> APIs.

Connection oriented APIs by definition require the application to 
control the connections, yes.

> Presumably if say Proton Messenger was the consumer you'd simply
> be able to take the ReplyTo in this case and use that as as the address
> when you do pn_message_set_address(message, address); So I think that
> there is some scope for confusion/complexity as to *exactly* what an
> address means as the interpretation is subtly different between
> connection oriented and message oriented paradigms.

I don't think there is any difference in interpretation, I think there 
is a difference in the nature and scope of the APIs, and what they imply 
about the division of responsibilities between the application and the 

> I guess that if you're always using node names on the container that the
> consumer is connected to then everything is OK, but if not isn't there
> scope for things getting a bit interesting - surely a consumer is
> decoupled from a producer so it doesn't necessarily know how it has set
> its reply to (as a node or a fully qualified address).

The decoupling of producers and consumers comes from having 
intermediaries between them.

Shielding an application from caring about the details of the reply to 
is subtly different from that sort of decoupling. It can be done in the 
same way through intermediaries, or it can be done by a library that 
handles establishing connections based on the addressing scheme used (as 
is the case for proton messenger).

> In AMQP 0.10 as far as I was aware the default reliability was actually
> at-least-once, or at any rate I don't believe that the default was
> unreliable. The reason I'm thinking this was because I always had to
> explicitly do link: {reliability: unreliable} for a couple of use cases
> where I didn't want my consumers to have to acknowledge the messages.
> This stuff above *seems* to point to the default reliability in AMQP 1.0
> as being unreliable - is that observation correct, if so there's clearly
> an inconsistency between AMQP 0.10 and 1.0

Even in 0-10, topic subscriptions were unreliable by default, while 
queue subscriptions were reliable. The same applies to 1.0.

>>> 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).
> Just because it's not documented doesn't mean it doesn't exist ;-p
> If that were the case........

I should have said 'described'. When I implemented this (based on 
previous discussions on the list with you in fact), I described what I 
had done and invited comments.

I follow the AMQP 1.0 related stuff on the lists of a couple of other 
implementations and have never seen this capability mentioned. I suspect 
it hasn't yet been implemented elsewhere. If any of the other brokers 
want to follow the same scheme, that would be great. If they have a 
better suggestion I would be happy to adapt/adopt as appropriate also. I 
am very keen to see greater interoperability.

>  So don't get me wrong I really do like message
> selectors, but I also think that the legacy headers stuff really ought
> to be able to support everything the current AMQP 0.10 model can,
> especially as it's *nearly* there.

I think striving to find a way to do the same sorts of things over 1.0 
as is possible over 0-10 is indeed important. However I think the 
emphasis should be on finding ways that have the best chance of being 
more widely adopted.

I'm not opposed to any enhancement or improvement of the headers binding 
(especially where it remains backward compatible), but to be honest its 
not going to be high on my own list of priorities as I doubt it would 
ever be adopted by any other broker.

>> 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.
> Pleeeeeaaaaaassssseee :-)
> Seriously, finding a way to work through the hyphen issue would be awesome.

What did you think of Andrew's suggestion? I.e. using [] to delimit 
awkward 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.
> I'm not quite sure I understand what you mean here, as I understand it
> "selector: " is a qpid shortand, but I *thought* that over the wire that
> got translated to a filter with a descriptor
> apache.org:selector-filter:string

It does. The issue is that ActiveMQ does not actually look at the 
descriptor. It looks only at the key in the filter set (which is not 
correct). As Andrew points out, we could modify the key we send on the 
wire as it wouldn't affect how the Qpid brokers interpret the filter, I 
just haven't got around to making that change.

> Actually that reminds me - so in JMS I could specify selectors on the
> link as with qpid::messaging, but the JMS API also allows selectors to
> be specified from the Session |*createConsumer
> <http://docs.oracle.com/javaee/5/api/javax/jms/Session.html#createConsumer%28javax.jms.Destination,%20java.lang.String%29>*(Destination
> <http://docs.oracle.com/javaee/5/api/javax/jms/Destination.html>
> destination, String
> <http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html>
> messageSelector)|
> I probably shouldn't as this, but..... are you suggesting that at the
> moment with Qpid JMS specifying it from the Session will result in a
> different syntax on the link attach? If so will they both work with the
> Qpid brokers?

I don't understand the question. Calling createConsumer() in JMS will 
cause a receiving link to be attached, much like createReceiver() in 
qpid::messaging. The selector is associated as a filter on this link in 
both cases and should behave identically.

(You can specify a selector for receivers from topics as well as queues)

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

View raw message