Hi Ben, I also worked with IBM MQ for several years. I have started with Artemis from reading the documentation, and continue to check it when something is not clear for me. I think it is also necessary to have some real use cases for Artemis because it is not possible to gain a lot of experience using only test labs.
I'm not sure that I completely understood the question, but I would like to share my experience which is based on using both products (IBM MQ and ActiveMQ Artemis). There are some things which are common for "classic" message brokers like IBM MQ, ActiveMQ Classic and Artemis, other things are different. For example, messages can be durable (persistent) or non-durable. Messages in the queues are consumed and removed from the queue when it is acknowledged by the client as delivered. The main difference is in the address model of ActiveMQ Artemis. Queue in IBM MQ is like anycast address in Artemis with anycast queue. Topic in IBM MQ is like a multicast address with queues which are also subscriptions. There are no separate objects like subscription and queue to which the subscription delivers its messages. It is possible to make the subscriptions like in IBM MQ - we have experimented creating multicast addresses with diverts (rules to move messages from "topic address" to other addresses with anycast queues), and it works. In this case, divert looks like a subscription in IBM MQ. It also allows different address settings for different consumers. Subscription or divert can use a filter (like selector in IBM MQ). Divert can be used in some other cases, for example like an alias queue in IBM MQ, and it can copy or move messages. There are some other queue types which have no analog in IBM MQ, for example ring queues, last-value queues. When we tried to use our standard naming for queues (for example, words separated with dots), we have experienced problems because "." is a reserved symbol in the subscription name (it is also a queue name) - it is used as a separator between client id and subscription and this problem occurs only when using Artemis Core libraries. One address can be used for anycast and multicast, and it is a real mess. Clients can auto-create queues with incorrect routing type (if it is permitted to create queues), after some release the name changes, and unused queues are piled up with messages. Some clients can read multicast queue using fully-qualified queue name like "address::queue", other clients cannot, and I don't have enough knowledge to understand the difference. About clusters. Cluster with multiple active nodes in Artemis works like load-balancing cluster in IBM MQ, but it has a redistribution mechanism which moves messages to the node where the consumer is connected. But it adds some overhead to move messages between nodes. When a client connects to one broker instance, it receives cluster topology information and can connect to any live node of the cluster. Sometimes it is necessary to turn off using topology for client-side load balancing, for example if client needs to connect to another port with SSL. Remote queues and sender/receiver channels in IBM MQ: it is possible to create core bridges between two Artemis servers or clusters to send messages from one message broker to another. There are many things which it is easier to configure in Artemis, and other things which can cause problems. For example, Artemis has an audit logging which can log all messages passed through message broker, and it works out-of-box. Messages are logged with all headers and without payload. There are also a lot of built-in metrics which can be gathered using Prometheus. It is easier to configure high availability and resilience in Artemis because it has several HA mechanisms. I have used primary/backup with replication. It was easy to configure LDAP authentication and authorization using groups. There are some problems with the management web console. Permissions for the management console are configured separately from permissions on the broker like in two different applications, and there is no way to reload management.xml without restarting the broker. But if someone wants to send a message using management console, it checks if user has send permissions on the broker (not only in the management console). And there is no application like IBM MQ Explorer for Artemis. It is possible to use JMSToolBox only for some scenarios like sending test messages, listing and browsing queues. After some experience with Artemis I mentioned that IBM MQ is more stable and more tolerant to the situations when large number of messages are left in the queues. Maybe we have to tune up journal and paging settings in Artemis. Also we did not find a way to restrict the number of messages in the particular queue. It is not necessary to have Java programming skills, but IMHO it is better to have at least an experience of running Java application servers. Sometimes in the open-source world something does not work as expected, it is where Java developer skills can be very useful. Maybe source code is the best documentation (at least it is always up to date). вс, 25 февр. 2024 г. в 20:03, Ben F. Zhou <[email protected]>: > Greetings, ... > > I'm trying to learn ActiveMQ, have installed and setup Artemis in my home > lab, created multiple broker instances on several Linux severs, and could > access the broker instances from the Web GUI. I do understand the core > architecture. But I'm still lost in finding a way to understand how to use > the brokers, like putting messages to queues and get the them flow through > a network of broken instance. > > Since I couldn't find a single internet post over the puzzle I'm stuck > with, I guess my problem has to be a matter of mind-set. I have worked with > IBM MQ for over two decades, and things there seem too natural for me, like > setting up a network of interconnected queue managers, channels, > local/remote queues, clusters etc. But where should I start with ActiveMQ? > Do I have to be a Java programmer to use ActiveMQ? I also tried to find an > ActiveMQ administration training course on Udemy, but could find nothing. > > Thanks much for any advice! > Ben > > -- С уважением, Александр Миловидов
