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.
Exactly.
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
library.
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: [email protected]
For additional commands, e-mail: [email protected]
