JMS dans WildFly

Dans WildFly, les fonctionnalités de messaging JMS sont prises en charge par ActiveMQ Artemis. De ce fait, la configuration du subsystem messaging-activemq a pas mal de similitudes avec celle d’un serveur ActiveMQ Artemis autonome.

La fonctionnalité de messaging n’est pas présente dans la configuration par défaut de WildFly. Pour l’avoir, il faut utiliser le fichier de configuration standalone-full.xml ou le profil full, en mode domaine.

Il est aussi possible d’ajouter la fonctionnalité de messaging au profil par défaut en ajoutant l’extension org.wildfly.extension.messaging-activemq, le subsystem urn:jboss:domain:messaging-activemq.

Toute la configuration JMS se fait dans ce subsystem messaging-activemq. Plus précisément, elle se fait dans son élément enfant <server>.

Destinations

Le terme destination est générique aux queues et topics. Les destinations sont dans des éléments <jms-queue> et <jms-topic>. Pour chaque destination, la configuration minimal est constituée d’un nom de destination et d’au moins une entrée JNDI.

<server name="default">
  <!-- ... -->
  <jms-queue name="SWq" entries="java:/jms/queue/SwQueue"/>
  <jms-topic name="SWt" entries="java:/jms/topic/SwTopic"/>
  <!-- ... -->
</server>

La queue et le topic peuvent aussi être déclarés par jboss-cli :

[host:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=SWq:add(entries=[java:/jms/queue/SwQueue])

[host:9990 /] /subsystem=messaging/hornetq-server=default/jms-topic=SWt:add(entries=[java:/jms/topic/SwTopic])

On notera que la queue et le topic configurés ci-dessus ne sont pas accessible à distance puisqu’ils n’ont pas d’entrée JNDI dans l’espace de nommage java:jboss/exported/.

Sécurité

Accès distant

Pour accéder à une destination, un client externe à WildFly passe par JNDI via un accès distant. Cet accès est sécurisé par l'`ApplicationRealm`.

Permissions par destinations

L’ajout de permissions à une destination ou un ensemble de destinations se fait par des security-settings.

   <security-settings>
      <security-setting match="jms.queue.SWq">
          <role name="swuser" consume="true" send="true" />
      </security-setting>
   </security-settings>

Un security-setting avec match="#" s’applique à toutes les destinations. Un security-setting avec match="jms.queue.SWq" ne s’applique qu’à la queue JMS dont le nom est SWq.

La liste des permissions est la suivante :

  • send

  • consume

  • createDurableQueue

  • deleteDurableQueue

  • createNonDurableQueue

  • deleteNonDurableQueue

  • manage

La même configuration par cli :

[host:9990 /] /subsystem=messaging-activemq/server=default/security-setting="jms.queue.SWq":add
[host:9990 /] /subsystem=messaging-activemq/server=default/security-setting="jms.queue.SWq"/role=swuser  \
                    :add(send=true, consume=true)

Attention, l’authentification se fait par l’appel de la méthode connectionFactory.getConnection(username, password). Il n’y a aucune propagation automatique lorsqu’on appelle connectionFactory.getConnection().

Destinations de gestion

Dans les destinations de gestion, je regroupe la dead letter queue qui reçoit les messages qui n’ont pas pu être consommés et l'expiry queue qui reçoit les messages dont la date d’expiration est dépassée.

  <address-setting name="#"
                   dead-letter-address="jms.queue.DLQ"
                   expiry-address="jms.queue.ExpiryQueue" />

Expiry Queue

La file d’expiration reçoit les messages qui ont expiré. Cela peut être dû à une durée de vie limité fixée par le producteur, avant l’envoi :

producer.setTimeToLive(10000L);

L’expiration peut aussi être provoquée par un script jboss-cli, pour tous les messages d’une destination :

[host:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=SwQueue:expire-messages

Pour un unique message d’une destination, identifié par son JMSMessageID :

[host:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=SwQueue                      \
                    :expire-message(message-id=ID:f0671793-faec-11e2-9d0d-2d43143133bb)

Dead Letter Queue

La file de rebuts reçoit les messages qui n’ont pas pu être délivrés, ou plus précisément ceux qui n’ont pas pu être livrés après un nombre d’échecs égal au paramètre max-delivery-attempts. C’est le cas par exemple pour des messages consommés dans le cadre de transactions annulées (rollback).

La valeur par défaut de ce paramètre est 10, mais il peut être modifié :

[host:9990 /] /subsystem=messaging-activemq/server=default/address-setting=#                      \
                    :write-attribute(name=max-delivery-attempts, value=5)

Il est aussi possible de forcer l’envoi de tous les messages d’une destination dans la DLQ :

[host:9990 /] /subsystem=messaging-activemq/server=default/jms-queue=SWq                          \
                    :send-messages-to-dead-letter-address()

Pour un unique message d’une destination, identifié par son JMSMessageID :

[host:9990 /] /subsystem=messaging-activemq/hornetq=default/jms-queue=SWq                         \
                    :send-message-to-dead-letter-address(message-id=ID:6c28635a-faef-11e2-9d0d)