Fraser,
This is all great feedback, thanks again (and apologies for delayed
response).
The concept of a 'shared subscription' is I think an important one to be
able to model with 1.0. I'll give that some more thought and come back
with some suggestions.
I also agree it is important to be able to control what happens when a
(slow or disconnected) subscriber starts building up a backlog of
messages. In many cases I think this is something that should really be
a policy on the exchange or 'topic' (i.e. how much backlog are any of
the subscribers allowed to build and what happens when they exceed that).
It may also be important to allow some per-subscription control. AMQP
1.0 allows 'capabilities' to be requested (for the link, or for the
source) and this is an extension point that could be used (however
capabilities are simple strings, not name-value pairs). It also allows
link properties to be specified, which would be another mechanism we
could use and as it is name-values would be more suitable for setting
per-subscription backlog sizes perhaps.
The intention for selectors when used with an exchange is to filter
*before* enqueueing, i.e. to further restrict the set of messages the
subscriber sees without having those build up in some broker side temp
queue. That isn't yet done, but I have a JIRA open for it.
[Specifically with respect to the headers exchange, I'm not sure it
offers much benefit over selectors (once working as expected). I would
need to do some benchmarking to be sure, but the matching logic in the
headers exchange is not particularly clever and my guess would be there
would be little difference in performance as compared with evaluation of
an equivalent selector.]
The selector syntax the c++ broker supports (in 0.22) is as defined in
the registered extension. Though there may be one or two gaps still to
be implemented (e.g. access to all the AMQP 1.0 defined fields) it does
not deviate into non-standard syntax in any way. The c++ client should
be able to use selectors against the java broker over 1.0 (I haven't yet
got around to testing that however), or indeed anything else that
supports that selector syntax (e.g. SwiftMQ).
I very much agree with the desire to get greater interoperablity and
cohesion, both within Qpid and more broadly for AMQP. My intention when
writing the notes was to describe how the client maps to 1.0 and
separately how 1.0 maps to the broker, in order to be more mindful of
alternative mixes of components.
I think the key with the 1.0 work is to identify the scenarios that
require extensions to the core specification and use the 1.0 defined
extension points in an intuitive and natural way to expose the required
functionality. The extensions can then be registered or refined and
ultimately progressed to standards.
Thanks again for all the feedback, it is very helpful!
--Gordon
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
