Description of problem: When a client use an ambiguous address (both the queue and exchange of the same name exists) and do not explicitly specify the node type, the queue is used by default over amqp1.0. No exception/warning is printed out. There is following exception in the same scenario when using amqp0-10 client: Ambiguous address, please specify queue or topic as node type (return code is non-zero, message is not sent) The clients shall behave the same way where possible. Version-Release number of selected component (if applicable): qpid-cpp-*-0.22-29 How reproducible: 100% Steps to Reproduce: 1. qpid-config add queue node 2. qpid-config add exchange topic node 3. ./spout --connection-options "{ protocol : 'amqp1.0' }" node Actual results: No exception/warning reported, message is sent towards the queue when ambiguous node is used Expected results: Exception is reported, message is not sent when ambiguous address is used and node type not explicitly specified Additional info: # qpid-config add queue node # qpid-config add exchange topic node # $cppapi/spout node Ambiguous address, please specify queue or topic as node type # echo $? 1 # $cppapi/spout --connection-options "{ protocol : 'amqp1.0' }" node # echo $? 0 # qpid-stat -q queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ========================================================================================================================= node 1 1 0 65 65 0 0 1
Though the client is not informed in any way of the ambiguity, a warning is logged by the broker when the node matches both a queue and an exchange and no specific type is specified. There is clearly a difference in behaviour between 1.0 and 0-10 here, but I'm not 100% convinced it is wrong as it is. In 0-10, the namespace for queues and exchanges is clearly separate. The messaging API creates the illusion of a unified node namespace on top of that. Resolution is done by the client using standard 0-10. In 1.0 on the other hand there is the expectation of a single node namespace for containers, the resolution happens on the server and the mechanism for passing the type is not standard 1.0. The ambiguity can be dealt with by creating a topic to expose the exchange over 1.0 by another name that doesn't clash with a queue. I'm happy to hear counter-arguments, and the change is not difficult to make, but at present I feel on balance the difference in behaviour between 0-10 and 1.0 is justified in terms of 'better' behaviour for each. Thoughts?
Confirmed, following warning is logged by the broker: [Protocol] warning Ambiguous node name; node could be queue or exchange, assuming queue I'm not claiming that the 1.0 behavior is necessarily wrong. These kind of bugs are filled due to Vienna requirements for 0-10/1.0 equivalent functionality and address string compatibility. I personally do not have any objection to leave the behavior as it is. So feel free to "close/won't fix" or better change to documentation bug.
(In reply to Petr Matousek from comment #2) > These kind of bugs are filled due to Vienna requirements for 0-10/1.0 > equivalent functionality and address string compatibility. Understood, and I really appreciate you raising these discrepancies. Exact equivalence isn't always possible however, and in this case I feel it would impact another requirement (which may not be explicitly stated for Vienna, but is important nevertheless), that the broker expose its functions over 1.0 in as natural a way as possible, relying on extensions only where it must. Justin: I'm inclined to leave the behaviour as is for this one. Do you have an opinion?
(In reply to Gordon Sim from comment #3) > Exact equivalence isn't always possible however, and in this case I feel it > would impact another requirement (which may not be explicitly stated for > Vienna, but is important nevertheless), that the broker expose its functions > over 1.0 in as natural a way as possible, relying on extensions only where > it must. > > Justin: I'm inclined to leave the behaviour as is for this one. Do you have > an opinion? I agree that it's better to "look forward" and not hold over a 0-10 behavior for the 1.0 protocol. The requirement is stated with little flexibility. If we did it over again, I'd insist on a "reasonable exceptions" clause so we can make judgment calls like this. As Petr mentions, it would be nice to document this change in behavior.
Changing to a documentation bug.
Note that the difference is only visible using the c++ based qpid::messaging client against qpidd (the python 0-10 client also does not throw an exception in this case).
Documented here: http://deathstar1.usersys.redhat.com:3000/builds/18173-Messaging_Installation_and_Configuration_Guide/#Ambiguous_Addresses_in_AMQP_1.0
The content seems well only following text must be removed (it is not part of the exception): "(return code is non-zero, message is not sent)" It is possible to describe that the message is not sent and the return code is non-zero, but not as a part of the exception. This information is IMO not necessary and may be removed at all.
Removed spurious comment: http://deathstar1.usersys.redhat.com:3000/builds/18173-Messaging_Installation_and_Configuration_Guide/#Ambiguous_Addresses_in_AMQP_1.0
Content approved.