You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by GitBox <gi...@apache.org> on 2020/04/27 19:28:03 UTC
[GitHub] [activemq-artemis] clebertsuconic opened a new pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
clebertsuconic opened a new pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
gemmellr edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-621148356
I dont think this should have been added before https://issues.apache.org/jira/browse/ARTEMIS-2740 is addressed. I know that JIRA is new, but I see the issue was raised in comments here when this PR was raised last year, and the PR closed, but now reopened/updated and added anyway - with the tests still using annotations that are reserved. It seems unwise to add a new functionality that relies on/encourages this behaviour, given fixing that would then necessarily break any uses of this new functionality.
It also seems that now any use of filters where the key value isnt found in application properties is going to decode every annotation now. Unlikely to be great for performance, and especially not nice for folks who aren't even looking to filter on any annotations, which is likely to be most values for most people, and certainly every existing user up to this point given it wasn't even possible before.
The filter extensions spec in the AMQP TC (https://www.oasis-open.org/committees/document.php?document_id=66227) is currently proposing using "m.\<annotation-key\>" as a means of requesting filtering on the message-annotations map within an SQL based filter string. It might be worth aligning to that, as it would at least allow avoiding decoding annotations when folks have not asked for them to be filtered.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624280703
I can check for prefixes on a property if it matches the standard for message annotations..
But I can't implement m.,p. as this would break current functionality. (I actually the AMQP group should consider against such prefixes imposition).
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624172945
You may disagree.. but it's working as designed.. if users ever use Expressions, we are expected to hit a decode on the message.. nothing to be changed there.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624276489
@gemmellr / @tabish121 I really don't want to introduce m. p. or any other properties on filters.. as this is a broker funcationality that's independent from the protocols.
I actually wasn't part of the discussion. I think it's a bit strong position from the protocol specification dictating how a broker supposedly protocool agnostic should implement filters.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-623425542
Before this the Jira had added an invalid annotation. Recently there is no annotation changes and it’s just exposing the Jira.
I understand your concern and will address before the release.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] michaelandrepearce edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
michaelandrepearce edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624947711
I have to agree with Cleberts earlier comment amqp 1.0 was not meant to care if a sender or receiver is a broker, its agnostic. As such it really shouldnt be enforcing any broker specifics, by doing so it no longer is an agnostic protocol.
That said and it seems we have two camps in general here, those that are wanting strict conformist and thats important for their use case and those who need broker features that technically break strict conformance but for some users actually have business value for them such this filter ability in this pr and in other prs where sometimes to have a broker feature requires mutating (adding or amending) some amqp sections.
Could i suggest we have a broker flag in config that is called maybe "amqpConformance" where its set to STRICT or RELAXED, and going forwards when hit these issue simply use the flag to still allow it should end broker users wish to enable the RELAXED operation mode thats their prerogative.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624218550
it's not possible to implement filteres over annotations without parsing the annotations.. simply not possible!
if you use a filter on a property that is not being found anywhere.. the server will try to find it on annotations.
users usually don't set filters with empty properties.. so your concern here is really really a corner and not practical case IMO.
What I'm going to do is to use x-opt in any property on the server.. and when parsing for a property, it will then look for the property on annotations.. if still not found it will convert the _AMQ_ into a x-opt property.
I will send a PR.. but it's not possible to do this with 0 computational cost for someone using filters.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
gemmellr commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-625136367
> I have to agree with Cleberts earlier comment amqp 1.0 was not meant to care if a sender or receiver is a broker, its agnostic. As such it really shouldnt be enforcing any broker specifics, by doing so it no longer is an agnostic protocol.
There is no caring whether its a broker or anything else, so its not being broker-specific. It does define that certain parts of its standard message format are considered immutable such that recipients receive what senders actually sent in those parts, which they could then verify if desired. It also defines multiple other sections that are mutable should things want their messages mutated by intermediaries for reasons.
Being a component/platform agnostic protocol doesnt necessarily mean its an instant universal drop in replacement for all existing different protocols and behaviours. A particular mechanism underneath may differ from other protocols, but is known, i.e everything has a shared knowledge of how certain things are defined such as the format of the messages and armed with this anything/anyone can implement the same knowing they can then interoperate with other components doing the same. Going outwith such existing definitions can obviously make that interop bit a problem.
> Could i suggest we have a broker flag in config that is called maybe "amqpConformance" where its set to STRICT or RELAXED, and going forwards when hit these issue simply use the flag to still allow it should end broker users wish to enable the RELAXED operation mode thats their prerogative.
I think having a single global flag of this kind would be a very bad idea, far worse than having any individual one. Having any is annoying, but if they do exist at all they should at least be very specific to a particular case, minimising their effect. Using any such behaviour shouldnt require changing any/all the other behaviours too 'just because'.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624155850
``
"It also seems that now any use of filters where the key value isnt found in application properties is going to decode every annotation now. Unlikely to be great for performance, and especially not nice for folks who aren't even looking to filter on any annotations, which is likely to be most values for most people, and certainly every existing user up to this point given it wasn't even possible before."
``
@gemmellr: if you use expressions, that's an expected cost. no issues in there.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624274970
@tabish121 you could argue the same over application properties, and make users to use properties.
Users are not going to set a property filter into something that's already null...
This is not amqp filter, this is a broker functionality over JMS. and we don't only have AMQP as the protocol. The same filter would have to work across other protocols in case a client changed the protocol.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624155850
```
"It also seems that now any use of filters where the key value isnt found in application properties is going to decode every annotation now. Unlikely to be great for performance, and especially not nice for folks who aren't even looking to filter on any annotations, which is likely to be most values for most people, and certainly every existing user up to this point given it wasn't even possible before."
```
@gemmellr: if you use expressions, that's an expected cost. no issues in there.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] tabish121 commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
tabish121 commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624278379
I'm going to -1 this commit unit a proper solution is found then as this is a rather serious technical issue that needs to be worked out before any future release can provide this sort of functionality.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] tabish121 commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
tabish121 commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624239615
I don't think Robbie ever implied that the application of a message annotations filter should or could be a zero computational cost operation. What is being argued here (and rightly so) is that filtering on an AMQP message annotation should be an opt in filtering operation and not a by product of the broker walking into the message annotations section any time a filter doesn't hit on an application property in the AMQP message when it applies the filters.
Currently with Artemis users can't filter on message annotations in AMQP messages, if you want to give them that option then you should implement it following the recommendations from the AMQP Core TC draft specification that the filter should be an explicit "m." prefix on the message annotation property the user wishes to filter upon (m.x-opt-original-destination=foo) etc.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
gemmellr commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-621148356
I dont think this should have been added before https://issues.apache.org/jira/browse/ARTEMIS-2740 is addressed. I know that JIRA is new, but I see the issue was raised in comments here when this PR was raised last year, and the PR closed, but now reopened/updated and added anyway - with the tests still using annotations that are reserved. It seems unwise to add a new functionality that relies on/encourages this behaviour, given fixing that would then necessarily break any uses of this new functionality.
It also seems that now any use of filters where the key value isnt found in application properties is going to decode every annotation now. Unlikely to be great for performance, and especially not nice for folks who aren't even looking to filter on any annotations, which is likely to be most values for most people, and certainly every existing user up to this point given it wasn't even possible before.
The filter extensions spec in the AMQP TC (https://www.oasis-open.org/committees/document.php?document_id=66227) is currently proposing using "m.<annotation-key>" as a means of requesting filtering on the message-annotations map within an SQL based filter string. It might be worth aligning to that, as it would at least allow avoiding decoding annotations when folks have not asked for them to be filtered.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624218550
it's not possible to implement filters over annotations without parsing the annotations.. simply not possible!
if you use a filter on a property that is not being found anywhere.. the server will try to find it on annotations.
users usually don't set filters with empty properties.. so your concern here is really really a corner and not practical case IMO.
What I'm going to do is to use x-opt in any property on the server.. and when parsing for a property, it will then look for the property on annotations.. if still not found it will convert the _AMQ_ into a x-opt property.
I will send a PR.. but it's not possible to do this with 0 computational cost for someone using filters.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624175971
I got users asking for the feature, and you are basically opposing the feature is implemented.
It's such a simple addition. I don't see a reason to remove a filter, or even add a toggle to enable it or not.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
gemmellr commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624162802
I disagree its an expected cost. Existing uses may now do more work and go slower than before, for no gain. Plus if they haven't specifically asked to filter on an annotation, which again no existing use could be doing, then it shouldnt really be looking at them anyway, cost or not. It may even lead to incorrect/unexpected behaviour by doing so all of a sudden.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-620201388
This PR has been reworked to not change any semantics.. other than looking at the annotations on filter.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624155850
``
"It also seems that now any use of filters where the key value isnt found in application properties is going to decode every annotation now. Unlikely to be great for performance, and especially not nice for folks who aren't even looking to filter on any annotations, which is likely to be most values for most people, and certainly every existing user up to this point given it wasn't even possible before."
``
@gemmellr: if you use expressions, that's an expected cost. no issues in there. there isn't much we can do there, beyond tell users to not use expressions if they don't want the perf hit.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] michaelandrepearce commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
michaelandrepearce commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624947711
I have to agree with Cleberts earlier comment amqp 1.0 was not meant to care if a sender or receiver is a broker, its agnostic. As such it really shouldnt be enforcing any broker specifics, by doing so it no longer is an agnostic protocol.
That said and it seems we have two camps in general here, those that are wanting strict conformist and thats important for their use case and those who need broker features that technically break strict conformance but for some users actually have business value for them such this filter ability in this pr and in other prs where sometimes to have a broker feature requires mutating (adding or amending) some amqp sections.
Could i suggest we have a broker flag in config that is called maybe "amqpConformance" where its set to STRICT or RELAXED, and going forwards when hit these issue simply use the flag to still allow it should end broker users which to enable the RELAXED operation mode.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624280703
I can check for prefixes on a property if it matches the standard for message annotations..
But I can't implement m.,p. as this would break current functionality. (I actually think the AMQP group should consider against such prefixes imposition).
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] tabish121 edited a comment on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
tabish121 edited a comment on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624278379
I'm going to -1 this commit until a proper solution is found then as this is a rather serious technical issue that needs to be worked out before any future release can provide this sort of functionality.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] clebertsuconic commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
clebertsuconic commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624276489
@gemmellr / @tabish121 I really don't want to introduce m. p. or any other properties on filters.. as this is a broker funcationality that's independent from the protocols.
I actually wasn't part of the discussion. I think it's a bit strong position from the protocol implementation dictating how a broker supposedly protocool agnostic should implement filters.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [activemq-artemis] gemmellr commented on pull request #2695: ARTEMIS-2372 Filtering on Message Annotations
Posted by GitBox <gi...@apache.org>.
gemmellr commented on pull request #2695:
URL: https://github.com/apache/activemq-artemis/pull/2695#issuecomment-624193941
I didn't suggest not supporting filtering annotations, or adding a toggle to enable it or not.
I do suggest:
- Not causing performance or correctness changes for existing users who are definitely not using the functionality, by having it decode and inspect things all of a sudden that it shouldnt be looking (as it hasnt been asked to, and it wasnt possible before).
- Not encouraging [further] violating the core AMQP spec and thus preventing interop with peers that might enforce what it says, when there are simple routes not to.
- Aligning with the "m." prefix the AMQP TC draft filter spec currently suggests for this functionality.
- In concert for these avoiding later causing breakage in the usage of these new users you aim satisfy, should the broker ever decide to actually adhere the specs later rather than doing it now before the functionality even exists.
----------------------------------------------------------------
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:
users@infra.apache.org