qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: The new QMF2 qpid-config appears to have some "quirks"
Date Tue, 05 Mar 2013 19:21:22 GMT
Hi Ted,
many thanks for the quick response I've commented inline below
> Frase,
> I think you're mostly correct about the way that qpidtoollibs should 
> work with regard to object-ids.  In QMFv1, the IDs were 
> broker-assigned and opaque.  In v2, they are composed of the values of 
> the referenced object's "index" properties.  This is why the id == 
> name assumption worked.  It might be more correct to do as you suggest 
> and compare to a properly formed getObjectId() result.
I guess that my take is that they are conceptually opaque whether we're 
talking V1 or V2. To be fair in the API spec 
https://cwiki.apache.org/qpid/qmfv2-api-proposal.html there's an 
interesting line which says:

An object identifier can be assigned to the object by the agent when the 
object is instantiated. Alternatively, a schema can define an object 
identifier by defining an ordered list of names of data items. In this 
case, the object identifier string is built by concatenating the string 
representations of the value of each named data item

So I guess there's at least some allusion to the concept that an 
ObjectId might in some circumstances be non-opaque, however there's no 
mention anywhere of how to specify the list of names.

Well that's not totally correct, in "class 
SchemaObjectClass(SchemaClass):" it has ".set_id_names([name-list]): set 
the value of the order list of names to use when constructing the object 
identifier." so the API could do this, but I've not seen anything 
obvious in management-schema.xml that points to this. You mention 
"index" in your response - so are you suggesting for example that the 
Exchange ObjectId comprises the vhostRef and the name concatenated in 
some way? The example in the spec shows simple concatenation, but from 
what I've seen the BrokerObject __getattr__ is looking for colon separators.

In any case I still think it's dangerous from the perspective of object 
references and think it's far safer to treat them as opaque and at the 
very least if one uses an object name as a target of an object reference 
that object's getObjectId *really* should return name in that case.

I know I'm labouring it a bit, but I spent ages trying to figure out 
what was going on 'cause I had assumed that it's something I'd done.

> With regard to using the topic exchange for replies, that was quite 
> deliberate.  There's really no benefit to using a different exchange 
> for replies and it makes writing ACL rules more difficult.  It also 
> makes it more difficult to use any form of federation for exchanging 
> messages.  I would consider deprecating the qmf.*.direct exchanges 
> altogether.

Re "There's really no benefit to using a different exchange for 
replies", hmm well yes I might agree with this comment but interestingly 
if you consider the code you'll see:

     self.tx = self.sess.sender("qmf.default.direct/broker")
     self.reply_to = "qmf.default.topic/direct.%s;{node:{type:topic}, 
link:{x-declare:{auto-delete:True,exclusive:True}}}" % \

So using the topic exchange in the replyTo is indeed using a different 
exchange for replies and I can't see what advantage this gives.

Re "I would consider deprecating the qmf.*.direct exchanges altogether".

I can't agree with you there. QMF is fundamentally implementing a 
request response pattern, which is in essence very much a point-to-point 
model. There's a bunch of work for service discovery (or in the case of 
the broker a "well know" alias subject of "broker" as used in self.tx 
above). Sending to a topic (to my mind at least) is about sending out a 
"broadcast" message, whereas with QMF it's pretty much sending a query 
to a given agent.

There's clearly a need to broadcast in the case of agent discovery, but 
in terms of agent query I'm not clear that it makes any sense at all so 
I'd normally expect each agent to have a different binding key. Even 
multiple instances of the same agent ought in general to have different 
names 'cause if not doing a get object request could lead to interesting 
message race conditions.

The bottom line is that I very much think that a direct exchange is by 
far and a way the most appropriate exchange to send message requests and 
responses in a request/response messaging pattern you are in effect 
sending a message directly to a unique named endpoint and asking for the 
response to be returned to a unique named endpoint. As  I say that feels 
very different from publishing to a topic that may have multiple 
independent subscribers. But even if publishing to a topic made sense 
(and I don't think it does) a replyTo is almost always asking for the 
response to be returned to a unique named endpoint (that's certainly the 
case in QMF).

If there's truly a use case whereby a service requester wishes the 
response to be broadcast to multiple recipients then I've got no 
quibbles there of using a topic exchange, but that's a relatively 
uncommon use case in request response messaging and I really don't think 
it's the case in QMF.

If you're suggesting "deprecating the qmf.*.direct exchanges altogether" 
you might as well argue for deprecating direct exchanges in general and 
(ab)using topic or header exchanges. IMHO QMF request/response is 
actually one of the classical messaging scenarios where it's entirely 
the right thing to do to use a direct exchange.

I don't disagree that it's possible to "emulate" the behaviour of a 
direct exchange using a topic exchange, but I think it's important to 
consider semantics and intent.

Best regards,

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

View raw message