[
https://issues.apache.org/jira/browse/ARTEMIS-2372?focusedWorklogId=431133&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-431133
]
ASF GitHub Bot logged work on ARTEMIS-2372:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 06/May/20 09:43
Start Date: 06/May/20 09:43
Worklog Time Spent: 10m
Work Description: gemmellr commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624546565
> Users are not going to set a property filter into something that's already
null...
They can though. I'm pretty sure I have actually even seen it done
previously. There are also various operations/behaviours that check/depend on
null values explicitly in particular ways.
> This is not amqp filter, this is a broker functionality over JMS.
Specifically about adding filtering AMQP message annotations by AMQP
consumers that sent a selector using an AMQP filter though, so it seems
relevant.
> I think it's a bit strong position from the protocol specification
dictating how a broker supposedly protocool agnostic should implement filters.
There is no dictation or imposition from the AMQP spec/TC that Artemis must
use "m.<key>". Its a completely new and entirely optional SQL-like filter (and
so not actually the filter being used by the broker or JMS client currently,
though no reason the syntax cant be supported by the broker) that would allow
for AMQP clients (which are mostly not JMS clients) to be able to filter the
AMQP messages sections in a consistent way against any AMQP server that
implements the filter. Nothing says Artemis needs to support it. It is a
broker-agnostic filter, but clearly not necessarily protocol-agnostic because
since it is an AMQP filter aimed at AMQP consumers filtering on sections of
AMQP messages. (Aside, not really important : there are also other non-SQL-like
filters for achieving similar or more specific results. Since you mentioned it,
there is also a "a." prefix for the application-properties section for the
SQL-like filter, though that one was made optional since its the traditional
section to filter on).
Nothing stops Artemis having other filters (as it already does) and using
other syntax(es) to achieve the result of filtering AMQP message annotations of
course. I just strongly think whatever it is shouldn't encourage AMQP messaging
use violating the AMQP specs reserved annotations, or result in sudden
unwittingly filtering on things (i.e. annotations) the user hasnt expressly
asked to filter given that could actually change/break the behaviour of their
systems. More so given its likely rarely going to be the case that the filter
identifier is actually an annotation, certainly currently since its never been
possible. I was merely suggesting aligning to an existing proposal on the
specific subject matter.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 431133)
Time Spent: 6.5h (was: 6h 20m)
> Support Filtering on Message Annotations
> ----------------------------------------
>
> Key: ARTEMIS-2372
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2372
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 2.9.0
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
