ActiveMQ Artemis
Important for documentation:
CORBA Problem: The Notify Service has several limitations, such as being
resource intensive and not scaling well with the number of
subscribers.
Requirements: should be as transparent as possible
having the same features and requirements of the previous
Notify Service implementation.
ACS Notification Channel alternative should hide as
much of DDS as possible.
∙ It must be possible to set QoS properties of channels.
∙ Event channels should never discard events and events
should be delivered to consumers in a timely manner.
[ Insertar documentación de Artemis acá]
Apache ActiveMQ Artemis implements the AMQP 1.0 specification. Any client that supports the 1.0 specification will be able to interact with Apache ActiveMQ Artemis.
IP:
As a default, on the Linux platform, if you have IPV6 support enabled in your kernel, the Java Runtime (since 1.4 version) will use IPV6 sockets to communicate. That’s perfectly fine, except that your network may not be configured for IPV6. So everything will be dropped…and nothing will ever be received on the consumer side (which maybe even does not support IPV6).
There’s a solution to this problem: Force IPV4 stack to be used by the Java Runtime. This can be done using a system property:
-Djava.net.preferIPv4Stack=true
IMPORTANT:
When creating the broker, this must be done using:
${ARTEMIS_HOME}/bin/artemis create --allow-anonymous --silent --force --user almamgr --password alma123 --port-offset 0 --data ./data --allow-anonymous --no-autotune --verbose --aio --java-options -Djava.net.preferIPv4Stack=true {target_dir}/mybroker --java-options
And this will create a broker that uses IPV4.
In the case of the broker created for this project, it is called “mybroker2”.
Clusters:
Apache ActiveMQ Artemis provides very configurable state-of-the-art clustering model where messages can be intelligently load balanced between the servers in the cluster, according to the number of consumers on each node, and whether they are ready for messages.
Apache ActiveMQ Artemis also has the ability to automatically redistribute messages between nodes of a cluster to prevent starvation on any particular node.
Bridges and routing:
Apache ActiveMQ Artemis bridges can be configured with filter expressions to only forward certain messages, and transformation can also be hooked in.
Apache ActiveMQ Artemis also allows routing between queues to be configured in server side configuration. This allows complex routing networks to be set up forwarding or copying messages from one destination to another, forming a global network of interconnected brokers.
Server JVM Settings
The run scripts set some JVM settings for tuning the garbage collection policy and heap size. We recommend using a parallel garbage collection algorithm to smooth out latency and minimise large GC pauses.
By default Apache ActiveMQ Artemis runs in a maximum of 1GiB of RAM. To increase the memory settings change the -Xms and -Xmx memory settings as you would for any Java program.
Broker configuration file
The configuration for the Apache ActiveMQ Artemis core server is contained in broker.xml. This is what the FileConfiguration bean uses to configure the messaging server.
Address Model
Addressing Model
Apache ActiveMQ Artemis has a unique addressing model that is both powerful and flexible and that offers great performance. The addressing model comprises three main concepts: addresses, queues, and routing types.
Address
An address represents a messaging endpoint. Within the configuration, a typical address is given a unique name, 0 or more queues, and a routing type.
Queue
A queue is associated with an address. There can be multiple queues per address. Once an incoming message is matched to an address, the message will be sent on to one or more of its queues, depending on the routing type configured. Queues can be configured to be automatically created and deleted.
Routing Types
A routing type determines how messages are sent to the queues associated with an address. An Apache ActiveMQ Artemis address can be configured with two different routing types.
Table 1. Routing Types
If you want your messages routed to... Use this routing type...
A single queue within the matching address, in a point-to-point manner. Anycast
Every queue within the matching address, in a publish-subscribe manner. Multicast
By default is Anycast
AMPQ Clients
QPid Proton:
Java JMS 1.1 Client (Apache QPid JMS based on Qpid Proton)
Reactive C++ Client (Apache Qpid Proton)
Reactive Python Client (Apache Qpid Proton)
According to the Requirements
| # | Title | User Story | Importance | Status | Notes |
|---|---|---|---|---|---|
| 1 | API must be available in C++, Java and Python | Developers use those three languages to implement the different parts of ALMA software, therefore the API must be provided in those three languages | Must Have | qpid supports all 3 languages | |
| 2 | The Notification Channel API must hide as much as possible of the underlying technology | The API must be common for all the technologies used to implement this API. This includes CORBA at the beginning | Must have | ||
| 3 | The possibility of setting the quality of service and administrative properties of channels must exist. | Each channel has different QoS requirements based on the role they play in whole ALMA system. The user must be able to set this up using the Configuration Database | Must Have | ||
| 4 | The API must be implemented in a high-performance manner to reduce the chances of events being discarded, if the QoS settings are set properly. | Each client (publisher or subscriber) must perform accordingly to prevent slow participants. The sending and reception of events should be done as quickly as possible. Each client consuming events from the API is responsible to handle each event timely, otherwise events could be lost. | Must Have | ||
| 5 | Notification Channel must decouple publishers from subscribers. | Must Have | |||
| 6 | Notification channel shall deliver events based on best-effort or reliable way. Depending of the QoS configuration. | Must Have | |||
| 7 | Events should be delivered to consumers in a timely manner | The events must be sent and received with the lowest latency possible. Acceptable values are in order of 100 [ms] | Must Have | ||
| 8 | Notification channel must support re-connection of clients | If the Event Channel goes down, the Channel must be re-created automatically. All the clients connected to the Event Channel shall reconnect to it. | Must Have | ||
| 9 | Notification Channels must provide introspection | The services associated, the channels and the clients must offer operational performance parameters introspection, in a way they can be monitored | Desirable | ||
| 10 | Notification channel should be fault tolerant | Problems in any network path should not affect communications that do not involve that path Events should be queued, up to some limit, in network paths that do have a problem. Data transmission between a publisher and consumer should not require the data be staged in a third place, like a central server. | Must have | ||
| 11 | Maintain event order | Events between the same publisher and consumer should be delivered in the same order | Must have |