On 09/05/2012 11:47 PM, Mark White wrote:
Hello, this is just a feeler to see if any sort of jira should be
opened and against which client(s):
Background: Connecting to a queue or exchange using the python 0.14
client library issues two calls: ExchangeQuery(name='obj_name',
id=serial(0), sync=True) and QueueQuery(queue='obj_name',
id=serial(1), sync=True). This is true whether or not the connection
has specified the node type.
Example queue connection: queueName; {create:always, delete:receiver,
node: {type: queue, durable: True, x-declare: {alternate-exchange:
'exchangeName'}, x-bindings: [{exchange: 'exchangeName', queue:
'queueName', key: 'binding.key'}]}}
Changing the connection string for an exchange which
node:{type:topic, x-declare: {type: <type>}} produces similar results
(both queries are performed every time).
Issue: Why are both ExchangeQuery and QueueQuery performed every time
a sender or receiver is created, if the node type is declared in the
connection string?
After speaking with some people, it sounds like the C++ client
libraries are not doing the same thing, but that wasn't confirmed.
I can confirm they do not do the same thing.
If the node type is *not* specified, its type must be determined in
order for senders/receivers to behave correctly. The c++ client does
this using an ExchangeBound call to the broker. The response to that
call indicates whether there is a queue with that name, or whether there
is an exchange of that name or both.
If the node type *is* specified in the address string, the c++ client
does not attempt to 'resolve' the node name in this manner.
Once the client determines what the node type is (either from the
address string or by querying the broker), it then issues a
QueueDeclare/ExchangeDeclare as appropriate (with the passive flag
determined by the create option in the address).
It's thought that the C++ client code only performs a lookup based on
the node type if it's specified.
As above, it is actually the opposite. The c++ client only attempts to
determine the type through a query if it is not explicitly specified in
the address string.
If that's the case, should the
libraries be made to operate the same,
Yes, they should. I actually have a JIRA assigned for this already:
https://issues.apache.org/jira/browse/QPID-3456, but I'm afraid I have
not got around to tackling it.
and if so, should the python
libraries change, or should the C++ libraries change? I haven't
looked at the JMS libraries yet, but the client I'm working with will
be using JMS, so that will need to be addressed as well.
As a general note, the way I found this was by setting up ACL rules
that limit users from querying for queues and exchanges they
shouldn't have access to. Because of the way the python code
operates, I had to allow access to both the exchange and the queue of
a common name, even though I knew, due to naming conventions, that it
would only ever be a queue or an exchange, not both.
If the node type is specified, in my view you should not require
permission to access both queue or exchange, but only whichever one is
specified.
However if it is *not* specified then I think it is reasonable that the
client requires permission to access both a queue and an exchange of
that name.
You could argue that you should only require the permission if the
queue/exchange exists. But that in itself allows unauthorised clients to
'see' which queues exchanges exist.
Now, there is currently a quirk in the c++ broker - a bug in my view -
that means the c++ client doesn't require both permissions when the type
is not specified. The handling of exchange-bound only requires access
permission for the exchange, even if a queue name is specified and checked.
So, my view, is that the python client should not have to query the
broker for both the exchange/queue if the type is specified and the
exchange-bound implementation on the broker should require queue access
permission if a queue name is specified.
That would I think bring the two clients into closer alignment (and
greater correctness in my view) with relatively small changes.
That isn't yet full alignment of course. However at present I believe
that a 1.0 implementation of the messaging API is more important and so
am pursuing that.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
