qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Questions on Addresses
Date Tue, 26 Aug 2014 09:23:20 GMT
On 08/25/2014 11:47 AM, Rob Godfrey wrote:
> While I was working on adding addressing support to the JMS 0-9-1 client
> [1] and looking at how I might implement a subscription where the
> subscription was to a set of queues (rather than a single queue) [2], I
> came across a couple of issues with the address implementation that I think
> I should probably discuss before I go ahead an "fix" them.
>
> Firstly the addressing syntax definition in
> http://qpid.apache.org/releases/qpid-trunk/programming/book/section-addresses.html#section-address-string-bnf
> defines the following:
>
> x-subscribe: { ... <subscribe-overrides> ... }
>
> However the JMS client looks for x-subscribes (note the plural).  I presume
> this is just a mistake and should be corrected (though probably allowing
> the pluralised version for backward compatibility).

Yes, in python and c++ it is x-subscribe, singular.

> Secondly I would think that an address which explicitly or implicitly
> defines its assertion policy to be "never" should not fail in the act of
> creation if the node does not exist (otherwise what is the point of assert:
> never ).

In c++ and python the assertions are used to verify specific aspects of 
the node (e.g. to ensure it is a queue or that it is durable or is an 
lvq etc) rather than the existence of the node.

Establishing a link to or from a node that does not exist will always 
fail (unless that node is to be created on demand).

>  However it seems that the JMS client always explicitly tests for
> the presence of either a queue or an exchange and if it finds neither (even
> if the policy is assert" never) it fails.

The reason for the test is that in 0-10, how you establish sender and 
receivers depends on whether the node in question is an exchange or a 
queue. In c++ at least, you can skip the querying by simply telling the 
client what node type it is, e.g.

   my-queue; {node:{type:queue}}

or

   my-exchange; {node:{type:topic}}

The c++ client however will always issue a 'declare' (with passive=true) 
before creating either a sender or receiver. This could be relaxed on 
the receiver side since the subscribe would fail anyway if the queue 
didn't exist (at present the check is on a common code path).

>  Moreover there are tests
> checking this behaviour.  I would like to change this behaviour also, as it
> prevents the creation of subscriptions to pseudo-nodes which are not queues
> or exchanges (for instance the multi queue subscription case).

So from an 0-10 perspective, for a receiver at least this pseudo-node is 
'like' a queue? I.e. you can issue a message-subscribe to it with the 
name of the pseudo-node in the queue field?

Would it ever make sense to create a sender to such a pseudo-node? Or 
would the sender always be to an exchange?

> Clearly the
> act of attempting to subscribe to something the broker cannot resolve will
> still result in an error on the broker side, which seems to me the expected
> behaviour of assert: never.
>
> Thoughts?

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).

> -- Rob
>
>
> [1] https://issues.apache.org/jira/browse/QPID-6037
>
> [2]  https://issues.apache.org/jira/browse/QPID-6040
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message