On 08/26/2014 11:15 AM, Rob Godfrey wrote:
> On 26 August 2014 11:23, Gordon Sim <gsim@redhat.com> wrote:
>> I'd suggest using an explicit type to indicate which 0-10 commands should
>> be issued when creating a receiver (and/or a sender). You may additionally
>> need to avoid declaring the queue if that is not valid for these
>> pseudo-nodes).
>>
>
> An explicit type on which element in the address. Obviously you need to
> explicitly need to state that the address should be treated as a queue
> node... but are you thinking of something else?
No, I just meant specifying that the node should be treated like a queue
as you say.
> If assert is false, and the type of the node is explicitly given, and
> creation is not requested, what is the rationale for declaring the queue
> before attempting subscription (both will result in a similar sort of
> error, won't they)?
The passive declare is mostly there for the send side, to try and give
you an error rather than having messages silently dropped. Having it on
the receive side is mostly because the two cases share common code (and
because at one time it was considered 'good practice' in AMQP to
passively declare queues before using them).
I don't think it would be hugely difficult to change this if anyone
needed it.
That said if the queues to subscribe to are actually conveyed in the
subscribe arguments, and the node name was some 'special' node, a bit
like the default exchange, then perhaps you could just define a long
form name - e.g. qpid.nameless - and have passive declare of the return
true for that on name(?).
> I'd certainly agree that if assert is false, or create is true, or the type
> isn't made explicit in the address string then you should expect that query
> or declare commands would be issued... But I'd think that if you provide an
> address that is basically saying "connect to this, don't check it, just do
> it - I've given you all the information you need" then we should do just
> that.
That is more or less what the c++ client does. If you tell it the node
is a queue, it does not try to resolve it or query any further
information about it, it just proceeds on the assumption that it is a
queue. The only problematic part is that that assumption causes it to
passively declare the queue before subscribing.
I think the 'ideal' fix for 0-10 JMS, assuming it's feasible on the code
side without huge upheaval, would be to do something similar, and skip
resolution/querying if the type is given.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
|