Skip to main content
Version: 2.75.x.x LTS

Provisioning providers

Messaging queue provisioning provider

Local messaging queue​

ActiveMQ Artemis is used as JMS Broker. For wildfly instances, Artemis 1.x is provided by the container. For standalone instances, Artemis 2.x is used and configured automatically.

On default, Artemis creates a queue with the name "Provisioning" (Artemis extends it with the prefix "jms.queue"). In addition, Artemis creates the two following queues:

  • An expiration queue with the name "ExpiryQueue". Messages whose configured time to live is expired are moved to this queue.
  • A dead letter queue with the name "DLQ". Messages are moved to this queue when the maximum of 10 failed delivery attempts has been reached.

The queue names are fix and cannot be changed. Internally, nevisIDM connects via an in-vm connector. External clients can access the queues via TCP.

The JMS queue for standalone instances supports AMQP protocols (besides the own "Core" protocol of ActiveMQ Artemis).

You can use the properties in the file nevisidm-prod.properties to configure the JMS provisioning module.

Messages are paged to disk, when the size of all messages in memory for an address exceeds the maximum size. Paging of messages is done transparently into and out of memory as they are needed.

Disk Space

Ensure that there is always enough disk space available for writing to the messaging queue. Writing to the messaging queue will block the current transaction when the corresponding disk reaches 99% disk usage. You set the messaging queue location in the property application.modules.provisioning.jmsqueue.storage.location of the nevisidm-prod.properties file.

WildFly

With wildfly deployment, make sure that the user of the JMS queue is configured and that the permissions for the queue are given. For more information, see JMS provisioning message persistence]".

Note that WildFly will be deprecated as of release 2.75.

The messaging can also be configured to provision events to a remote message queue. The events are transmitted with the AMQP protocol, therefore the remote message queue must support AMQP.

Remote messaging queue​

Note that if you configure a remote message queue, the local messaging queue is not exposed over TCP anymore.

WildFly

The remote messaging queue is only supported in the standalone deployment. It is possible to configure a JMS bridge]" in wildfly deployment for setups where messages must be provisioned to a remote queue.

Note that WildFly will be deprecated as of release 2.75.

Duplicate Messages

In case of failures after transmission but before acknowledgment, message transmission is repeated. Hence, the destination might receive duplicate messages after a failure. If supported, the destination queue provider should enable automatic duplicate message detection and removal.

Remote messaging queue setup​

To enable provisioning to a remote message queue, configure the messaging.remote.uri property in the " [nevisidm-prod.properties]" file. The following formats are supported:

  • A URI according RFC 2396 of the format <scheme>://<username>:<password>@<host>:<port>/<queuename>
  • An Azure service bus endpoint, that is, a Primary Connection String of the format:
  • Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<sasKeyName>;SharedAccessKey=<sasKey>=;EntityPath=<queuename>

Examples:

Example

# AMQP:
messaging.remote.uri=amqp://user:[email protected]:5672/remoteQueue
messaging.remote.uri=amqps://user:[email protected]:5671/remoteQueueTls
messaging.remote.uri=Endpoint=sb://example-namespace.servicebus.windows.net/;SharedAccessKeyName=ClientSharedAccessKey;SharedAccessKey=<SasKey>=;EntityPath=<queuename>
Endpoint=sb://nevisidm-test.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=hWmCLiwtWSeaEaTVTg=;EntityPath=remote-queue