Examples

First, run mvn clean package in the repository root to prepare a broker distribution in the artemis-distribution/target directory for use by the examples.

To run any example, simply cd into the appropriate example directory and type mvn verify or mvn install (For details please read the readme.md in each example directory).

Several examples use UDP clustering which may not work in your environment by default. On linux the command would be:

This command should be run as root. This will redirect any traffic directed to 224.0.0.0 to the loopback interface. On Mac OS X, the command is slightly different:

All the examples use the Maven plugin, which can be useful for running your test servers as well.

This is the common output when running an example. On this case taken from the Queue example:

You can use the profile -Pexamples to run multiple examples under any example tree.

For each example, you will have a created server under ./target/server0 (some examples use more than one server).

You have the option to prevent the example from starting the server (e.g. if you want to start the server manually) by simply specifying the -PnoServer profile, e.g.:

Also under ./target there will be a script repeating the commands to create each server. Here is the create-server0.sh generated by the Queue example. This is useful to see exactly what command(s) are required to configure the server(s).

The below list includes a preview of some examples in the Examples Repository. See the repository for more.

The broker also supports Application-Layer failover, useful in the case that replication is not enabled on the server side.

With Application-Layer failover, it’s up to the application to register a JMS ExceptionListener with the broker which will be called in the event that connection failure is detected.

The code in the ExceptionListener then recreates the JMS connection, session, etc on another node and the application can continue.

Application-layer failover is an alternative approach to High Availability (HA). Application-layer failover differs from automatic failover in that some client side coding is required in order to implement this. Also, with Application-layer failover, since the old session object dies and a new one is created, any uncommitted work in the old session will be lost, and any unacknowledged messages might be redelivered.

The bridge example demonstrates a core bridge deployed on one server, which consumes messages from a local queue and forwards them to an address on a second server.

Core bridges are used to create message flows between any two remote brokers. Core bridges are resilient and will cope with temporary connection failure allowing them to be an ideal choice for forwarding over unreliable connections, e.g. a WAN.

The browser example shows you how to use a JMS QueueBrowser.

Queues are a standard part of JMS, please consult the JMS 2.0 specification for full details.

A QueueBrowser is used to look at messages on the queue without removing them. It can scan the entire content of a queue or only messages matching a message selector.

The camel example demonstrates how to build and deploy a Camel route to the broker using a web application archive (i.e. war file).

The client-kickoff example shows how to terminate client connections given an IP address using the JMX management API.

The client-side-failoverlistener example shows how to register a listener to monitor failover events

The client-side-load-balancing example demonstrates how sessions created from a single JMS Connection can be created to different nodes of the cluster. In other words it demonstrates client-side load-balancing of sessions across the cluster.

This example demonstrates a clustered JMS durable subscription

This is similar to the message grouping example except that it demonstrates it working over a cluster. Messages sent to different nodes with the same group id will be sent to the same node and the same consumer.

The clustered-queue example demonstrates a queue deployed on two different nodes. The two nodes are configured to form a cluster. We then create a consumer for the queue on each node, and we create a producer on only one of the nodes. We then send some messages via the producer, and we verify that both consumers receive the sent messages in a round-robin fashion.

The clustered-jgroups example demonstrates how to form a two node cluster using JGroups as its underlying topology discovery technique, rather than the default UDP broadcasting. We then create a consumer for the queue on each node, and we create a producer on only one of the nodes. We then send some messages via the producer, and we verify that both consumers receive the sent messages in a round-robin fashion.

The clustered-standalone example demonstrates how to configure and starts 3 cluster nodes on the same machine to form a cluster. A subscriber for a JMS topic is created on each node, and we create a producer on only one of the nodes. We then send some messages via the producer, and we verify that the 3 subscribers receive all the sent messages.

This example demonstrates how to configure a cluster using a list of connectors rather than UDP for discovery

This example demonstrates how to set up a cluster where cluster connections are one way, i.e. server A -> Server B -> Server C

The clustered-topic example demonstrates a JMS topic deployed on two different nodes. The two nodes are configured to form a cluster. We then create a subscriber on the topic on each node, and we create a producer on only one of the nodes. We then send some messages via the producer, and we verify that both subscribers receive all the sent messages.

You can specify a maximum rate at which a JMS MessageConsumer will consume messages. This can be specified when creating or deploying the connection factory.

If this value is specified, then the broker will ensure that messages are never consumed at a rate higher than the specified rate. This is a form of consumer throttling.

The dead-letter example shows you how to define and deal with dead letter messages. Messages can be delivered unsuccessfully (e.g. if the transacted session used to consume them is rolled back).

Such a message goes back to the JMS destination ready to be redelivered. However, this means it is possible for a message to be delivered again and again without any success and remain in the destination, clogging the system.

To prevent this, messaging systems define dead letter messages: after a specified unsuccessful delivery attempts, the message is removed from the destination and put instead in a dead letter destination where they can be consumed for further investigation.

The delayed-redelivery example demonstrates how the broker can be configured to provide a delayed redelivery in the case a message needs to be redelivered.

Delaying redelivery can often be useful in the case that clients regularly fail or roll-back. Without a delayed redelivery, the system can get into a "thrashing" state, with delivery being attempted, the client rolling back, and delivery being re-attempted in quick succession, using up valuable CPU and network resources.

Diverts allow messages to be transparently "diverted" or copied from one address to another with just some simple configuration defined on the server side.

The durable-subscription example shows you how to use a durable subscription. Durable subscriptions are a standard part of JMS, please consult the JMS 1.1 specification for full details.

Unlike non-durable subscriptions, the key function of durable subscriptions is that the messages contained in them persist longer than the lifetime of the subscriber - i.e. they will accumulate messages sent to the topic even if there is no active subscriber on them. They will also survive server restarts or crashes. Note that for the messages to be persisted, the messages sent to them must be marked as durable messages.

The embedded example shows how to embed a broker within your own code using POJO instantiation and no config files.

The embedded-simple example shows how to embed a broker within your own code using regular XML files.

The exlusive-queue example shows you how to use exclusive queues, that route all messages to only one consumer at a time.

The expiry example shows you how to define and deal with message expiration. Messages can be retained in the messaging system for a limited period of time before being removed. JMS specification states that clients should not receive messages that have been expired (but it does not guarantee this will not happen).

the broker can assign an expiry address to a given queue so that when messages are expired, they are removed from the queue and sent to the expiry address. These "expired" messages can later be consumed from the expiry address for further inspection.

This examples shows how to build the Artemis resource adapters a rar for deployment in other Application Server’s

The http-transport example shows you how to configure the broker to use the HTTP protocol as its transport layer.

Usually, JMS Objects such as ConnectionFactory, Queue and Topic instances are looked up from JNDI before being used by the client code. These objects are called "administered objects" in JMS terminology.

However, in some cases a JNDI server may not be available or desired. To come to the rescue the Core JMS client also supports the direct instantiation of these administered objects on the client side, so you don’t have to use JNDI for JMS.

Interceptors allow an application to hook into the messaging system to handle various events.

Similar to the Interceptor example, but using AMQP interceptors.

Similar to the Interceptor example, but using interceptors on the client rather than the broker.

Similar to the Interceptor example, but using MQTT interceptors.

The jaas example shows you how to configure the broker to use JAAS for security. JAAS is leveraged to delegate user authentication and authorization to existing security infrastructure.

The jms-auto-closeable example shows how JMS resources, such as connections, sessions and consumers, in JMS 2 can be automatically closed on error.

The jms-completion-listener example shows how to send a message asynchronously and use a CompletionListener to be notified of the Broker receiving it.

The jms-bridge example shows how to setup a bridge between two standalone brokers.

The jms-context example shows how to send and receive a message to/from an address/queue using a JMSContext.

A JMSContext is part of JMS 2.0 and combines the JMS Connection and Session Objects into a simple Interface.

The jms-shared-consumer example shows you how can use shared consumers to share a subscription on a topic. In JMS 1.1 this was not allowed and so caused a scalability issue. In JMS 2 this restriction has been lifted so you can share the load across different threads and connections.

The jmx example shows how to manage a broker using JMX.

The large-message example shows you how to send and receive very large messages. The Core client supports the sending and receiving of huge messages, much larger than can fit in available RAM on the client or server. Effectively, the only limit to message size is the amount of disk space you have on the server.

Large messages are persisted on the server so they can survive a server restart. In other words, the broker doesn’t just do a simple socket stream from the sender to the consumer.

The last-value-queue example shows you how to define and deal with last-value queues. Last-value queues are special queues that discard any messages when a newer message with the same value for a well-defined last-value property is put in the queue. In other words, a last-value queue only retains the last value.

A typical example for last-value queue is for stock prices, where you are only interested by the latest price for a particular stock.

The management example shows how to manage the broker using JMS Messages to invoke management operations.

The management-notification example shows how to receive management notifications from the broker using JMS messages. The broker emits management notifications when events of interest occur (e.g. consumers are created or closed, addresses are created or deleted, security authentication fails, etc.).

The message-counters example shows you how to use message counters to obtain message information for a queue.

The message-group example shows you how to configure and use message groups. Message groups allow you to pin messages so they are only consumed by a single consumer. Message groups are sets of messages that has the following characteristics:

The message-group2 example shows you how to configure and use message groups via a connection factory.

Message Priority can be used to influence the delivery order for messages.

It can be retrieved by the message’s standard header field 'JMSPriority' as defined in JMS specification version 1.1.

The value is of type integer, ranging from 0 (the lowest) to 9 (the highest). When messages are being delivered, their priorities will effect their order of delivery. Messages of higher priorities will likely be delivered before those of lower priorities.

Messages of equal priorities are delivered in the natural order of their arrival at their destinations. Please consult the JMS 1.1 specification for full details.

This example demonstrates how to set up a primary server with multiple backups

This example demonstrates how to set up a primary server with multiple backups but forcing failover back to the original primary server

By default, consumers buffer messages from the server in a client side buffer before you actually receive them on the client side. This improves performance since otherwise every time you called receive() or had processed the last message in a MessageListener onMessage() method, the Core client would have to go the server to request the next message, which would then get sent to the client side, if one was available.

This would involve a network round trip for every message and reduce performance. Therefore, by default, the Core client pre-fetches messages into a buffer on each consumer.

In some cases buffering is not desirable, and it can be switched off. This example demonstrates that.

The non-transaction-failover example demonstrates two servers coupled as a live-backup pair for high-availability (HA), and a client using a non-transacted JMS session failing over from primary to backup when the primary server is crashed.

Client connections can failover between primary and backup servers. This is implemented by the replication of state between primary and backup nodes. When replication is configured and a primary node crashes, the client connections can carry on and continue to send and consume messages. When non-transacted sessions are used, once and only once message delivery is not guaranteed and it is possible that some messages will be lost or delivered twice.

The Openwire example shows how to configure a broker to communicate with a JMS client that uses the OpenWire protocol.

You will find the queue example for OpenWire, and the chat example. The virtual-topic-mapping example shows how to map the ActiveMQ Virtual Topic naming convention to work with the address model.

The paging example shows how to support huge queues even when running in limited RAM. It does this by transparently paging messages to disk, and depaging them when they are required.

Standard JMS supports three acknowledgement modes: AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE, and DUPS_OK_ACKNOWLEDGE. For a full description on these modes please consult the JMS specification, or any JMS tutorial.

All of these standard modes involve sending acknowledgements from the client to the server. However in some cases, you really don’t mind losing messages in event of failure, so it would make sense to acknowledge the message on the server before delivering it to the client. This example demonstrates this extra acknowledgement mode.

The producer-rte-limit example demonstrates how to specify a maximum send rate at which a JMS message producer will send messages.

A simple example demonstrating a queue.

The queue-message-redistribution example demonstrates message redistribution between queues with the same name deployed in different nodes of a cluster.

A simple example demonstrating a JMS queue requestor.

The queue-selector example shows you how to selectively consume messages using message selectors with queue consumers.

The Reattach Node example shows how a client can try to reconnect to the same server instead of failing the connection immediately and notifying any user ExceptionListener objects. The broker can be configured to automatically retry the connection and reattach to the server when it becomes available again across the network.

An example showing how failback works when using replication. In this example a primary server will replicate all its Journal to a backup server as it updates it. When the primary server crashes the backup takes over from the primary server and the client reconnects and carries on from where it left off.

An example showing how failback works when using replication, but this time with static connectors

An example showing how to configure multiple backups when using replication

An example showing how failover works with a transaction when using replication

A simple example showing the JMS request-response pattern.

The scheduled-message example shows you how to send a scheduled message to an address/queue. Scheduled messages won’t get delivered until a specified time in the future.

The security example shows you how configure and use role based security.

The security-ldap example shows you how configure and use role based security & an embedded instance of the Apache DS LDAP server.

The security-keycloak example shows you how to delegate security with & an external Keycloak. Using OAuth of the web console and direct access for JMS clients.

The send-acknowledgements example shows you how to use the Core client’s advanced asynchronous send acknowledgements feature to obtain acknowledgement from the server that sends have been received and processed in a separate stream to the sent messages.

The slow-consumer example shows you how to detect slow consumers and configure a slow consumer policy.

This example shows how to embed a JMS broker into a Spring application.

The ssl-enabled shows you how to configure SSL when sending and receiving messages.

The static-selector example shows you how to configure a queue with static message selectors (filters).

The static-selector-jms example shows you how to configure a queue with static message selectors (filters) using JMS.

The stomp example shows you how to send and receive Stomp messages.

The stomp example shows you how to send and receive Stomp messages via a Stomp 1.1 connection.

The stomp example shows you how to send and receive Stomp messages via a Stomp 1.2 connection.

The stomp-websockets example shows you how to send and receive Stomp messages directly from Web browsers (provided they support WebSockets).

The symmetric-cluster example demonstrates a symmetric cluster set-up.

Clusters can b set up in many different topologies. The most common topology that you’ll perhaps be familiar with if you are used to application server clustering is a symmetric cluster.

With a symmetric cluster, the cluster is homogeneous, i.e. each node is configured the same as every other node, and every node is connected to every other node in the cluster.

A simple example demonstrating how to use a JMS temporary queue.

A simple example demonstrating a JMS topic.

With a topic hierarchy you can register a subscriber with a wild-card, and that subscriber will receive any messages sent to an address that matches the wild card.

The topic-selector-example1 example shows you how to send a message to a JMS Topic, and subscribe them using selectors.

The topic-selector-example2 example shows you how to selectively consume messages using message selectors with topic consumers.

The transaction-failover example demonstrates two servers coupled as a live-backup pair for high availability (HA), and a client using a transacted JMS session failing over from primary to backup when the primary server is crashed.

The broker implements failover of client connections between primary and backup servers. This is implemented by the sharing of a journal between the servers. When a primary node crashes, the client connections can carry and continue to send and consume messages. When transacted sessions are used, once and only once message delivery is guaranteed.

The stop-server-failover example demonstrates failover of the JMS connection from one node to another when the primary server crashes using a JMS non-transacted session.

The transactional example shows you how to use a transactional Session.

The xa-heuristic example shows you how to make an XA heuristic decision through the broker’s management interface. A heuristic decision is a unilateral decision to commit or rollback an XA transaction branch after it has been prepared.

The xa-receive example shows you how message receiving behaves in an XA transaction.

The xa-send example shows you how message sending behaves in an XA transaction.