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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
