Apache Artemis Documentation

Apache Artemis is a multi-protocol message broker designed to support various industry-standard protocols. This allows for cross-platform connectivity using clients written in languages such as Java, JavaScript, C, C++, Python, and .NET.

Supported protocols include:

• AMQP 1.0
• MQTT 3.1.1
• MQTT 5
• STOMP

Apache Artemis provides command-line performance test tools based on the JMS 2 API to stress test broker instances. These tools allow you to simulate various load scenarios, such as all-out throughput or specific target rates.

The available tools are:

• producer: Generates load using BytesMessage of a configured size. Can generate all-out throughput or target-rate load.
• consumer: Uses a MessageListener to consume messages sent by a producer.
• client: A combined tool that packs both producer and consumer functionality into a single command. This is the most common tool used for testing.

Using separate producer and consumer tools is useful for advanced scenarios like delaying consumer starts to test broker paging or running producers and consumers on different machines.

The artemis data CLI command provides a suite of tools for performing data maintenance, recovery, and migration on an Artemis broker instance. These tools allow you to interact with the message journal, export/import data, and perform recovery operations.

Available sub-commands:

• print: Reports on journal records (use on non-running servers).
• exp: Exports message data to a universal XML format.
• imp: Imports message data from an XML export into a running broker.
• encode: Converts journal files into an internal encoded string format.
• decode: Converts an internal encoded format back into journal files.
• compact: Compacts the journal of a non-running server.
• recover: Recovers (undeletes) messages from an existing journal into a new one.

Apache Artemis provides an extensive management API to modify server configuration, create/inspect resources (addresses, queues), and interact with messages. You can access this API through several interfaces, all of which support the same functionality:

• JMX: The standard way to manage Java applications.
• Jolokia: Exposes the JMX API via an HTTP interface.
• Core Client: Sends management operations using Core Client messages.
• JMS Client: Sends management operations using JMS Client messages.
• Web Console: A graphical web application.
• Command Line: A management utility for administrators.

The Apache Artemis Command Line Interface (CLI) allows you to manage broker instances, users, queues, and addresses. It is designed for human interaction and simple use cases. For automated processes or scripting, use the comprehensive management API which returns JSON output.

You can interact with the CLI in two ways:

1. Traditional CLI commands: Execute individual commands from your terminal (e.g., ./artemis [COMMAND] [PARAMETERS]).
2. Custom Shell: Enter an interactive session using ./artemis or ./artemis shell. The shell reuses connection information (broker URI, username, password) across commands within the same session.

# Traditional command usage
./artemis help

# Interactive shell usage
./artemis shell

Federation allows for the transmission of messages between brokers without the requirement of a cluster. This makes it ideal for scenarios involving Wide Area Networks (WAN), cross-region communication, or connecting brokers in different administrative domains (e.g., different configurations, users, or versions).

There are two primary types of federation:

1. Address Federation: Similar to multicast. Every message sent to an address on the source broker is delivered to all queues on that broker, as well as to the connected federated broker and all its attached queues. This is only supported with multicast addresses.
2. Queue Federation: Allows multiple receivers on different machines to act as a single logical queue. This is useful for load balancing across WAN or cross-region boundaries where clustering is not feasible.

Address federation allows multiple Apache Artemis brokers to share messages across addresses. It functions similarly to multicast over connected brokers: every message sent to an address on Broker-A is delivered to all queues on that broker, and also to Broker-B and all its attached queues.

Key characteristics:

• Dynamic Linking: It links to addresses in upstream or downstream brokers.
• Automatic Queue Creation: The downstream broker automatically creates a durable queue on the remote (upstream) address to consume and copy messages locally.
• Low Configuration Overhead: Upstream brokers do not need reconfiguration to accept new downstream federations; you only need to ensure the downstream broker has the necessary permissions for the address.