Hello. 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 ( https://activemq.apache.org/artemis/docs/1.2.0/management.html, 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 avoided.
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 'org.apache.activemq.artemis.api.core.ActiveMQNonExistentQueueException: 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. Questions. 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. PS. 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. Thanks, Kristo Kuusküll
