You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by GitBox <gi...@apache.org> on 2021/11/01 13:27:56 UTC
[GitHub] [qpid-broker-j] alex-rufous commented on pull request #113: QPID-8565: [Broker-J] Enhancement of ACL rule predicates evaluation
alex-rufous commented on pull request #113:
URL: https://github.com/apache/qpid-broker-j/pull/113#issuecomment-956234276
> CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT properties are deprecated and they are not supported.
That is not a precise statement. The support for CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT had been dropped a while ago. I deleted it completely as the warning was misleading. It was stating that the feature was deprecated whilst in fact it was completely removed. The deprecated feature should work as expected.
> Actual implementation silently parses and adds a new predicate. This is the worst scenario because:
>
> 1. "CONNECTION_LIMIT" and "CONNECTION_FREQUENCY_LIMIT" are silently parsed but the code does not perform expected check.
>
> 2. The rule itself becomes unmatchable because any object never has the property "CONNECTION_LIMIT" or "CONNECTION_FREQUENCY_LIMIT". Hence, any object can not match with the rule.
IMHO, handling CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT without implementation did not look right to me.
Marec, are you planning to restore the behaviour behind CONNECTION_LIMIT and CONNECTION_FREQUENCY_LIMIT ?
>
> The main aim of this changes is performance. Hence, I would like to keep the chain of rule predicates as short as possible. The RulePredicate.Any does not perform any check and so it can be omitted in the chain.
IMHO, check for "any" looked like a premature optimisation to me. Have you tested a performance impact? I anticipate that performance impact from having an extra predicate in chain should be neglectable. The code readability has improved significantly without additional "any" check.
--
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.
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org