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. It's thought that the C++
client code only performs a lookup based on the node type if it's specified.
If that's the case, should the libraries be made to operate the same, 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.
Example acl rules needed when using python client:
acl allow <groupName> access exchange name=queueName
acl allow <groupName> access queue name=queueName
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
