On 04/16/2012 11:24 AM, Rob Godfrey wrote:
On 16 April 2012 12:03, Gordon Sim<[email protected]> wrote:
On 04/16/2012 09:42 AM, Rob Godfrey (Created) (JIRA) wrote:
[Java AMQP 1.0] Update JMS Filter implementations to use new proposed
descriptors
------------------------------**------------------------------**
---------------------
Key: QPID-3949
URL:
https://issues.apache.org/**jira/browse/QPID-3949<https://issues.apache.org/jira/browse/QPID-3949>
Project: Qpid
Issue Type: Bug
Components: Java Broker, Java Client
Affects Versions: 0.17
Reporter: Rob Godfrey
Assignee: Rob Godfrey
Fix For: 0.17
Update the Java AMQP 1.0 implementation to use the filter descriptors
defined here:
http://people.apache.org/~**rgodfrey/amqp-1.0/apache-**filters.xml<http://people.apache.org/%7Ergodfrey/amqp-1.0/apache-filters.xml>
Couple of comments on this proposal:
(1) It seems like translating from JMS property names to something more
generally applicable in AMQP in the JMS client would be from some
perspectives at least most 'natural'. That way the knowledge of JMS names
remains in the component directly concerned with implementing that
specification. It could be as simple as a string replacement of JMS name by
field name of corresponding AMQP 1.0 field name.
In this case the name of the filter could also be made a little more
generic. Likewise as specified there is no need to have 'jms' in the name
of the no-local filter as it is useful and supported for other use cases as
well.
The main driver here is that for people implementing AMQP 1.0 over an
existing JMS implementation they do not wish to have to translate the
filters from JMS to AMQP and then back again...
The message properties themselves are 'translated' into the AMQP 1.0
equivalents and then back again when transferring the message.
Translating the filter string for that same mapping seems reasonable to me.
It doesn't seem particularly arduous either (unless I'm missing
something); its just replacing one name with another.
For pure AMQP 1.0
implementations such as Qpid this obviously seems less natural. I think
there is a good case to be made that we should define an SQL like query
syntax which allows evaluation of all properties and annotations of an AMQP
1-0 message, however I think that is a separate task.
I'd like a selector that makes sense to use from other clients. Ideally
I'd like the underlying filter to be the same for such cases whether
sent by a JMS client or any other.
Forcing all components to adopt JMS naming seems (even) less desirable
than having the JMS components translate to a more AMQP friendly naming
scheme.
While I can see the desire to have a single capability for the two filters
driven by JMS, there is also a view that tying them together is not
necessary. You could support no-local but not the full selector filter.
Perhaps we could have distinct capabilities for the filters and then have a
more all-encompassing capability for a more complete JMS mapping?
For the final JMS mapping I think that the most likely way forward is to
specify that a server may offer one of a number of different filter types
that have the expressive power as JMS filters, and that clients must be
capable of using which filter syntax (from the approved list) the server
supports. Discussions amongst the AMQP implementers have never been able
to agree a single syntax that all can agree on based upon the different
histories of their products. Putting the burden on the client is somewhat
easier as we can produce an Apache licensed open source conversion function
that given a JMS selector string will compile the necessary AMQP 1.0 filter
expression. Since JMS clients must (by definition) be written in Java at
some level this should be enough for anyone writing a JMS client.
That certainly seems a useful, pragmatic approach for a JMS client
*implementation* such as Qpid. It seems a little weak as a standard JMS
mapping however, though clearly that point is for another list.
(In passing, such a function would make translating to AMQP names in
place of JMS names in the selector even less arduous).
(2) I am leaning to the view that allowing lists in the 'legacy AMQP
exchange binding' filters would be a simpler and more direct expression of
the legacy support than the generic and/or/not combinators.
The and/or/not expressions will be required anyway and as such I am keen to
add them now. The idea is generally that you should be able to combine
different sorts of filters which may be very specific and not expressible
easily in terms of property values (like no-local).
Point taken in general, but given you can define multiple filters for a
given link (i.e. combine in the 'AND' sense) are there more concrete
use-cases at present?
I'm keen for registered extensions not to get too far ahead of
implementations. Adding is generally easier than removing or modifying.
A limited set of filters with wide support is better than a wider range
of filters each with limited support.
Without modifying the actual capabilities of the different exchange types,
only the 'or' would be valid and even in that case the actual list would
need to consist only of the filters valid for the exchange type. For the
topic and direct exchanges a list of keys gives - in my view - a more
obvious indication of the actual capability.
As above I think the logical operations are a necessary set of filters, I'm
reluctant to add an alternative way of achieving the same ends for a single
use case.
I see it quite differently.
The goal appears to me to be tactical and specific: defining filters
that correspond to the routing behaviour defined for the standard
exchange types in previous incarnations of the specification so that
implementations (such as Qpid) based on those can support pub-sub
patterns by exposing exchanges as nodes supporting the appropriate
filter type.
Within this scope, the question is whether to support multiple bindings
from the same exchange for a given subscriber, and if so how best to do
that.
One approach, which I am suggesting, covers this through a minimal
change to the legacy filter definitions.
Another approach, as proposed by you, is to expand the scope to a more
general filtering solution, adding general purpose boolean operators.
I feel this goes further than is needed for a tactical solution while
not going far enough for a strategic solution. I feel the requirements
for the general solution are still too vague.
I am not suggesting adding an alternative way; I am suggesting keeping a
more limited scope for the tactical solution to the immediate goals.
The code for existing exchange implementations is going to be distinct
from any more general purpose implementation in the future anyway.
Moreover for the Java Broker you can currently qualify the
binding-key filter with a secondary (JMS) selector in AMQP 0-9 and 0-10, so
that your actual binding is ( binding-key1 AND selector1) OR (binding-key2
AND selector2) OR ... The proposal to just use lists of binding keys would
not allow for this functionality.
Expressing filtering capabilities of a node is more complex in the
proposed approach; you need to define not simply what filters are
supported but the valid ways in which they can be assembled.
If the goal is exposing the standard exchange types in 1.0 that seems
less desirable to me. It seems more likely to lead to a situation where
implementation specific, under-specified combinations of the primitives
emerge in an ad-hoc fashion.
Of course we don't want to rule out use cases for no reason, but this
case, as a Qpid specific extension, is at least different in scope.
I'd also suspect it is of much narrower applicability.
You could still have binding-key AND selector - through two separate
filters on the source - which would cover what I understand to be the
motivating use case for that feature i.e. a selector on a topic consumer
in JMS.
The only cases not covered are where you want to combine multiple such
pairs. If there is a real need for that, I'd rather see it defined as a
special legacy filter of its own.
Given the JMS style selector filter, what would be the use case for the
more generic combinators beyond simple 'or' lists for legacy exchanges?
Other implementers are very keen that selectors be specified in terms of an
AST (so a client side selector might be encoded as something like
and(equals(app-property("my-prop"), "my-value"),
less-than(message-annotation("foo-size"), 42)) as opposed to a string
"application-properties.my-prop = 'my-value' and
message.annotation.foo-size< 42"
Is there a reason for that? Having the parsing done on the broker seems
somewhat simpler to me on the face of it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
