On 26 August 2014 13:58, Gordon Sim <[email protected]> wrote: > 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(?). > > > Yes - I'm not necessarily averse to that, more that I don't want to have to also fake it in QueueQuery, ExchangeBound, etc... it'd be nice if there was a way to turn off the checking in the client(s) such that if you have an intermediary that just magics up addresses on demand then it can do so while not actually telling lies in response to other queries. Similarly there may be nodes like the AMQP management node that are not really queues and not really exchanges, but you should be able to address them through AMQP 0-x.
> 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. > > > Yeah - my work in progress does exactly this (basically put a break; at the end of each of the case statements in the switch I pasted previously). It just means that some of the tests "fail" because they are testing exactly this behaviour. If no-one else strenuously objects to this change in the behaviour when an address is not defined with assert, then I shall commit this. -- Rob > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
