On 08/26/2014 11:15 AM, Rob Godfrey wrote:
On 26 August 2014 11:23, Gordon Sim <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
