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: [email protected]
For additional commands, e-mail: [email protected]
