[
https://issues.apache.org/jira/browse/QPID-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marek Laca updated QPID-8487:
-----------------------------
Description:
We are using the Java broker with more than 1000 accounts and 40000 individual
ACL rules. This amount of ACL rules has a significant impact on the throughput
of the broker, therefore an optimization is needed.
*Current implementation*
There is the class called RuleSet that wraps the list of the rules and it is
responsible for finding a matching rule. The RuleSet contains internal
map/cache that could contain the relevant rules for given subject, operation,
object type.
Every access control of the user action goes throw two steps in the RuleSet:
# Broker looks for the relevant list of rules in the cache. If the cache does
not contain the rules then the broker will iterate over entire rule list and
filter the relevant rules for given operation, object type and subject.
# Broker scans the relevant rules and applies the first matching rule.
The cache is 3 tiers map with subject, operation and object type as key (in
this order). The top map is a synchronized weak hash. Hence the cache is used
only if the same subject (pointer equality) checks rules for the same operation
and object type multiple times.
I have tried to send 1000 messages to the same exchange by the same user and
the cache was never used. It looks like that every send action created a new
subject. The broker iterated over the whole rule list again and again.
*Proposed implementation*
I propose to introduce RuleInspector object that can check the internal rule
list and looks for the first rule that matches. The RuleInspector will be based
on the composite patter, the generic inspector will delegate work to a more
specialized inspector and so on.
_Tier structure:_
# The RuleSet itself is the top generic inspector.
# The rule inspectors for given operation and object type. These inspectors
will contain the relevant rules for given operation and object type and can be
prepared after the loading of the ACL file or rule list. The rules can be group
by the operation and object type immediately.
# The rule inspectors for given operation, object type and subject/principals.
The inspector for given principals/subject identities can be cached in a map.
Every subject has a set of principals and the rule list provides a set of
identities. The intersection of these two set produces a set of relevant
principals that have an impact on rule matching. Hence this set of relevant
principals is a suitable key of the cache.
The cache can be populated with the inspectors for none or a single relevant
principal directly after the loading.
The rule object can be transformed to a simple rule that matches only the
specified criteria. There will be different simple rules derived from firewall
criterion, updates attributes, properties and the simple rule will check only
the criterion that is needed.
was:
We are using the Java broker with more than 1000 accounts and 40000 individual
ACL rules. This amount of ACL rules has a significant impact on the throughput
of the broker, therefore an optimization is needed.
*Current implementation*
There is the class called RuleSet that wraps the list of the rules and it is
responsible for finding a matching rule. The RuleSet contains internal
map/cache that could contain the relevant rules for given subject, operation,
object type.
Every access control of the user action goes throw two steps in the RuleSet:
# Broker looks for the relevant list of rules in the cache. If the cache does
not contain the rules then the broker will iterate over entire rule list and
filter the relevant rules for given operation, object type and subject.
# Broker scans the relevant rules and applies the first matching rule.
The cache is 3 tiers map with subject, operation and object type as key (in
this order). The top map is a synchronized weak hash. Hence the cache is used
only if the same subject (pointer equality) checks rules for the same operation
and object type multiple times.
I have tried to send 1000 messages to the same exchange by the same user and
the cache was never used. It looks like that every send action created a new
subject. The broker iterated over the whole rule list again and again.
*Proposed implementation*
I propose to introduce RuleInspector object that can check the internal rule
list and looks for the first rule that matches. The RuleInspector will be based
on the composite patter, the generic inspector will delegate work to a more
specialized inspector and so on.
_Tier structure:_
# The RuleSet itself is the top generic inspector.
# The rule inspectors for given operation and object type. These inspectors
will contain the relevant rules for given operation and object type and can be
prepared after the loading of the ACL file or rule list. The rules can be group
by the operation and object type immediately.
# The rule inspectors for given operation, object type and subject/principals.
The inspector for given principals/subject identities can be cached in a map.
Every subject has a set of principals and the rule list provides a set of
identities. The intersection of these two set produces a set of relevant
principals that have an impact on rule matching. Hence this set of relevant
principals is a suitable key of the cache.
The cache can be populated with the inspectors for none or a single relevant
principal directly after the loading.
_Single rule evaluation_
The rule can have many matching criteria: firewall or dynamic criterion,
updates attributes, required properties. It is very generic but typical rule
has only a few criteria or none.
The rule object can be transformed to a simple rule that matches only the
specified criteria. There will be different simple rules derived from firewall
criterion, updates attributes, properties and the simple rule will check only
the criterion that is needed.
> [Broker-J] Enhance ACL rule evaluation
> --------------------------------------
>
> Key: QPID-8487
> URL: https://issues.apache.org/jira/browse/QPID-8487
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Marek Laca
> Priority: Major
> Labels: ACL, Broker, Java, Performance
>
> We are using the Java broker with more than 1000 accounts and 40000
> individual ACL rules. This amount of ACL rules has a significant impact on
> the throughput of the broker, therefore an optimization is needed.
> *Current implementation*
> There is the class called RuleSet that wraps the list of the rules and it is
> responsible for finding a matching rule. The RuleSet contains internal
> map/cache that could contain the relevant rules for given subject, operation,
> object type.
> Every access control of the user action goes throw two steps in the RuleSet:
> # Broker looks for the relevant list of rules in the cache. If the cache
> does not contain the rules then the broker will iterate over entire rule list
> and filter the relevant rules for given operation, object type and subject.
> # Broker scans the relevant rules and applies the first matching rule.
> The cache is 3 tiers map with subject, operation and object type as key (in
> this order). The top map is a synchronized weak hash. Hence the cache is used
> only if the same subject (pointer equality) checks rules for the same
> operation and object type multiple times.
> I have tried to send 1000 messages to the same exchange by the same user and
> the cache was never used. It looks like that every send action created a new
> subject. The broker iterated over the whole rule list again and again.
> *Proposed implementation*
> I propose to introduce RuleInspector object that can check the internal rule
> list and looks for the first rule that matches. The RuleInspector will be
> based on the composite patter, the generic inspector will delegate work to a
> more specialized inspector and so on.
> _Tier structure:_
> # The RuleSet itself is the top generic inspector.
> # The rule inspectors for given operation and object type. These inspectors
> will contain the relevant rules for given operation and object type and can
> be prepared after the loading of the ACL file or rule list. The rules can be
> group by the operation and object type immediately.
> # The rule inspectors for given operation, object type and
> subject/principals. The inspector for given principals/subject identities can
> be cached in a map. Every subject has a set of principals and the rule list
> provides a set of identities. The intersection of these two set produces a
> set of relevant principals that have an impact on rule matching. Hence this
> set of relevant principals is a suitable key of the cache.
> The cache can be populated with the inspectors for none or a single relevant
> principal directly after the loading.
> The rule object can be transformed to a simple rule that matches only the
> specified criteria. There will be different simple rules derived from
> firewall criterion, updates attributes, properties and the simple rule will
> check only the criterion that is needed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
