[ https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185492#comment-17185492 ]
ASF subversion and git services commented on ARTEMIS-2886: ---------------------------------------------------------- Commit 90853409a04bed9f64787447528defe869213b52 in activemq-artemis's branch refs/heads/master from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9085340 ] ARTEMIS-2886 optimize security auth Both authentication and authorization will hit the underlying security repository (e.g. files, LDAP, etc.). For example, creating a JMS connection and a consumer will result in 2 hits with the *same* authentication request. This can cause unwanted (and unnecessary) resource utilization, especially in the case of networked configuration like LDAP. There is already a rudimentary cache for authorization, but it is cleared *totally* every 10 seconds by default (controlled via the security-invalidation-interval setting), and it must be populated initially which still results in duplicate auth requests. This commit optimizes authentication and authorization via the following changes: - Replace our home-grown cache with Google Guava's cache. This provides simple caching with both time-based and size-based LRU eviction. See more at https://github.com/google/guava/wiki/CachesExplained. I also thought about using Caffeine, but we already have a dependency on Guava and the cache implementions look to be negligibly different for this use-case. - Add caching for authentication. Both successful and unsuccessful authentication attempts will be cached to spare the underlying security repository as much as possible. Authenticated Subjects will be cached and re-used whenever possible. - Authorization will used Subjects cached during authentication. If the required Subject is not in the cache it will be fetched from the underlying security repo. - Caching can be disabled by setting the security-invalidation-interval to 0. - Cache sizes are configurable. - Management operations exist to inspect cache sizes at runtime. > Optimize security auth > ---------------------- > > Key: ARTEMIS-2886 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2886 > Project: ActiveMQ Artemis > Issue Type: Improvement > Reporter: Justin Bertram > Assignee: Justin Bertram > Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Both authentication and authorization will hit the underlying security > repository (e.g. files, LDAP, etc.). For example, creating a JMS connection > and a consumer will result in 2 hits with the *same* authentication request. > This can cause unwanted (and unnecessary) resource utilization, especially in > the case of networked configuration like LDAP. > There is a rudimentary cache for authorization, but it is cleared *totally* > every 10 seconds by default (controlled via the > {{security-invalidation-interval setting}}), and it must be populated > initially which still results in duplicate auth requests. -- This message was sent by Atlassian Jira (v8.3.4#803005)