Bug 1048151

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.