90853409a0
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. |
||
---|---|---|
.github/workflows | ||
.mvn/wrapper | ||
.settings | ||
artemis-boot | ||
artemis-cdi-client | ||
artemis-cli | ||
artemis-commons | ||
artemis-core-client | ||
artemis-core-client-all | ||
artemis-core-client-osgi | ||
artemis-distribution | ||
artemis-docker | ||
artemis-dto | ||
artemis-features | ||
artemis-hawtio | ||
artemis-jdbc-store | ||
artemis-jms-client | ||
artemis-jms-client-all | ||
artemis-jms-client-osgi | ||
artemis-jms-server | ||
artemis-journal | ||
artemis-junit | ||
artemis-maven-plugin | ||
artemis-protocols | ||
artemis-ra | ||
artemis-rest | ||
artemis-selector | ||
artemis-server | ||
artemis-server-osgi | ||
artemis-service-extensions | ||
artemis-tools | ||
artemis-web | ||
artemis-website | ||
docs | ||
etc | ||
examples | ||
integration/activemq-spring-integration | ||
scripts | ||
tests | ||
.RELEASING.md.swo | ||
.asf.yaml | ||
.gitignore | ||
.project | ||
.travis.yml | ||
LICENSE | ||
NOTICE | ||
README.md | ||
RELEASING.md | ||
artemis_doap.rdf | ||
mvnw | ||
mvnw.cmd | ||
pom.xml |
README.md
ActiveMQ Artemis
This file describes some minimum 'stuff one needs to know' to get started coding in this project.
Source
For details about the modifying the code, building the project, running tests, IDE integration, etc. see our Hacking Guide.
Build Status
Building the ASYNC IO library
ActiveMQ Artemis provides two journal persistence types, NIO (which uses the Java NIO libraries), and ASYNCIO which interacts with the linux kernel libaio library. The ASYNCIO journal type should be used where possible as it is far superior in terms of performance.
ActiveMQ Artemis does not ship with the Artemis Native ASYNCIO library in the source distribution. These need to be built prior to running "mvn install", to ensure that the ASYNCIO journal type is available in the resulting build. Don't worry if you don't want to use ASYNCIO or your system does not support libaio, ActiveMQ Artemis will check at runtime to see if the required libraries and system dependencies are available, if not it will default to using NIO.
To build the ActiveMQ Artemis ASYNCIO native libraries, please follow the instructions in the artemis-native/README.
Documentation
Our documentation is always in sync with our releases at the Apache ActiveMQ Artemis website.
Or you can also look at the current master version on github.
Examples
To run an example firstly make sure you have run
$ mvn -Prelease install
If the project version has already been released then this is unnecessary.
Each individual example can be run using this command from its corresponding directory:
$ mvn verify
If you wish to run groups of examples then use this command from a parent directory (e.g. examples/features/standard):
$ mvn -Pexamples verify
Recreating the examples
If you are trying to copy the examples somewhere else and modifying them. Consider asking Maven to explicitly list all the dependencies:
# if trying to modify the 'topic' example:
cd examples/jms/topic && mvn dependency:list
Open Web Application Security Project (OWASP) Report
If you wish to generate the report for CCV dependencies, you may run it with the -Powasp profile
$ mvn -Powasp verify
The output will be under ./target/dependency-check-report.html for each sub-module.