397cef699a
After a node is scaled down to a target node, the sf queue in the target node is not deleted. Normally this is fine because may be reused when the scaled down node is back up. However in cloud environment many drainer pods can be created and then shutdown in order to drain the messages to a live node (pod). Each drainer pod will have a different node-id. Over time the sf queues in the target broker node grows and those sf queues are no longer reused. Although use can use management API/console to manually delete them, it would be nice to have an option to automatically delete those sf queue/address resources after scale down. In this PR it added a boolean configuration parameter called cleanup-sf-queue to scale down policy so that if the parameter is "true" the broker will send a message to the target broker signalling that the SF queue is no longer needed and should be deleted. If the parameter is not defined (default) or is "false" the scale down won't remove the sf queue. |
||
---|---|---|
.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 | ||
.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.