activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristo Kuusküll <>
Subject [Artemis] Clustering and Management interface
Date Wed, 25 May 2016 08:35:59 GMT

We have used Artemis for some time now with one live-node cluster. Our
approach has been, that all queues and addresses are created automatically
on micro-services startup, using Artemis management interface/API (, using JMS
messages). This has been very flexible approach especially when having lots
of micro-services. Every micro-service knows which queues and addresses it
needs, especially re-delivery and DLA settings on addresses it consumes,
and so the need for central registry (i.e. central broker.xml) has been

We are now investigating of adding another live-node to the cluster, but it
turned out that our current approach does not work well in a cluster with
many live-nodes.

Basically the management API creates queues and addresses only in one node,
where the particular JMS session is connected to, lets say it is nodeA and
lets also say that the queue name is 'jms.queue.MyQueue10'.

Now, when a consumer connects to nodeB, it will just get
AMQ119017: Queue jms.queue.MyQueue10 does not exist', even when auto
creating and auto deleting queues is enabled in nodeB. At the same time
consuming a queue (lets say jms.queue.X), which does not exist in nodeA,
works (the queue is automatically created in nodeB).

A side note, we discovered, that diverts created over management API are
not persistent, they are gone when the Artemis is restarted.

Is the management API not intended for multi live-node cluster scenario and
all configuration should happen via broker.xml (having identical queues and
addresses configuration in all nodes)?

If so, is there a way to change and apply broker.xml changes without
restarting Artemis? Because it seems, that every message "lives" in one
node only (i.e. no mirroring like in RabbitMQ), then every restart will
delay some messages, making the Artemis cluster not high-available when
modifying queues and addresses configuration. I can think that scaling-down
could be one approach, but it may be slow with millions of messages.

One case of "the problem" can be reproduced with example
'apache-artemis-1.2.0/examples/features/clustered/clustered-queue', when
commenting out 'jms' section in broker.xml-s. When the test connects to
second node, it will fail with queue not exists exception.

Kristo Kuusküll

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message