This looks really interesting. I've certainly been wondering about JMS
style message selectors for a while, it was on my "TODO" list to have a
play with when I get a break from QMFing so that's one I can park :-)
I think that this is a pretty important new feature that we should
publicise properly and keep users properly in the loop on.
I've got a couple of questions though.
1) I was looking through the Jira list that Irina Boverman sent out the
other day and noticed https://issues.apache.org/jira/browse/QPID-1766
which looks to have originated back in 2009. There seemed to be a fairly
long comment thread on that Jira but I'm not aware that it made it in to
any release? Andrew's work seems unrelated (other than being another
implementation of message selectors). Does anyone have the background??
The Xquery approach seemed quite interesting (and I guess consistent
with the XML exchange) does anyone have an idea of the performance
differences between that approach and Andrew's??
2) The approach for describing the selectors on the client side looks to
be done in the AddressString, That looks like a pretty good approach and
is consistent with a lot of things in Qpid but:
a) ISTR that with JMS the selector was passed from client to broker
using an "x-" property (can't recall exactly the
property but I'm pretty sure that it started x- whereas this
uses "qpid.selector") "qpid.selector" in itself isn't a big deal
but I'd be keen on absolute compatibility between C++ and Java
at both the broker and client level. I'd go so far as to
say interoperability is a prerequisite.
b) Following on from a) so does the Java client/broker allow
message selectors to be specified in an AddressString in
addition to being specified in createConsumer() on Session.
c) Following on from b) is there an intention to enhance the
qpid::messaging Session interface to provide an overloaded
createReceiver() method to take an Address and a message
selector. This last one is possibly a little moot and
arguably a little redundant but (apart from making things very
consistent with JMS) one advantage is that it allows one
to separate the concepts of subscription and filtering if so
desired. As an example I've got some cases where I've got
a mixture of C++ and Java consumers that subscribe to the same
data feed. As it happens some use different subsets so we've ended up
with quite contrived headers bindings to enable this, but it might be
cleaner to use selectors. In this case I'd quite like to enforce the
same Address String subscription (as that's the general "type" of the
data that they are allowed to see) but allow them to choose to
filter subsets if the so wish.
I'm quite excited by this though - nice one!!
Frase
On 28/02/13 21:59, Chug Rolke wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9494/#review17208
-----------------------------------------------------------
Ship it!
Ship It!
- Chug Rolke
On Feb. 18, 2013, 5:21 p.m., Andrew Stitcher wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9494/
-----------------------------------------------------------
(Updated Feb. 18, 2013, 5:21 p.m.)
Review request for qpid, Gordon Sim and Kenneth Giusti.
Description
-------
This is a potential first cut at JMS style selectors for the c++ broker and
client.
Currently what's implemented:
Selector parser/evaluator:
Parse a subset of the selector language including:
Conditional expressions : "=" "<>" "IS NULL" "IS NOT NULL" "NOT "AND" "OR"
All values are treated as strings (no numerics or boolean literals) so there
are no numeric
operators or comparison operators (strings can only be compared for equality)
"LIKE" & "NOT LIKE", "IN" are not (yet) supported.
To specify a selector you add a link property called qpid.selector to a queue
type address, for example:
queue; {link:{qpid.selector:"amqp.delivery_mode='PERSISTENT' or not
TransactionType='red'"}}
The code is currently implemented in the 0-10 code paths of the broker and the
messaging library:
The selector is sent from client to broker as an argument property in the
message subscription.
Still to do:
* amqp 1.0 support.
* Improved "special" identifier handling - currently not all the amqp.*
identifiers are handled and
we may need some extra message hooks to get the rest uniformly across 0-10
and 1.0 messages.
* Work on parser/evaluator:
** Handle type other than string
** Booleans
** Numerics
** Numeric operators and comparisons
** more complex operators:
*** string: "LIKE", "NOT LIKE", "IN"
*** numeric: "BETWEEN"
Having said all that needs still to be done, I'm reasonably happy that what's
currently there is useful and stable so could go into the tree is currently is.
This addresses bug QPID-4558.
https://issues.apache.org/jira/browse/QPID-4558
Diffs
-----
/trunk/qpid/cpp/src/CMakeLists.txt 1446233
/trunk/qpid/cpp/src/Makefile.am 1446233
/trunk/qpid/cpp/src/qpid/broker/Selector.h PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/Selector.cpp PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/SelectorExpression.h PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/SelectorExpression.cpp PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/SelectorToken.h PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/SelectorToken.cpp PRE-CREATION
/trunk/qpid/cpp/src/qpid/broker/SemanticState.h 1446233
/trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1446233
/trunk/qpid/cpp/src/qpid/client/amqp0_10/AddressResolution.cpp 1446233
/trunk/qpid/cpp/src/tests/CMakeLists.txt 1446233
/trunk/qpid/cpp/src/tests/Makefile.am 1446233
/trunk/qpid/cpp/src/tests/Selector.cpp PRE-CREATION
Diff: https://reviews.apache.org/r/9494/diff/
Testing
-------
Selector parser/evaluator tested reasonably thoroughly using new unit tests.
Current make check still works.
Informally tested selector functionality using qpid-send, qpid-receive.
Thanks,
Andrew Stitcher
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
