d50f577cd5
When a large message is replicated to backup, a pendingID is generated when the large message is finished. This pendingID is generated by a BatchingIDGenerator at backup. It is possible that a pendingID generated at backup may be a duplicate to an ID generated at live server. This can cause a problem when a large message with a messageID that is the same as another largemessage's pendingID is replicated and stored in the backup's journal, and then a deleteRecord for the pendingID is appended. If backup becomes live and loads the journal, it will drop the large message add record because there is a deleteRecord of the same ID (even though it is a pendingID of another message). As a result the expecting client will never get this large message. So in summary, the root cause is that the pendingIDs for large messages are generated at backup while backup is not alive. The solution to this is that instead of the backup generating the pendingID, we make them all be generated in advance at live server and let them replicated to backup whereever needed. The ID generater at backup only works when backup becomes live (when it is properly initialized from journal). |
||
---|---|---|
.mvn/wrapper | ||
.settings | ||
artemis-boot | ||
artemis-cdi-client | ||
artemis-cli | ||
artemis-commons | ||
artemis-core-client | ||
artemis-core-client-all | ||
artemis-distribution | ||
artemis-dto | ||
artemis-features | ||
artemis-jdbc-store | ||
artemis-jms-client | ||
artemis-jms-client-all | ||
artemis-jms-server | ||
artemis-journal | ||
artemis-junit | ||
artemis-maven-plugin | ||
artemis-native | ||
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 | ||
CMakeLists.txt | ||
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.
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.