> One address can be used for anycast and multicast, and it is a real mess.
Technically speaking this is possible, but it's discouraged in the documentation [1] not least because it can become "a real mess." > Clients can auto-create queues with incorrect routing type (if it is permitted to create queues) If the broker is auto-creating queues with the incorrect routing type that's likely a bug - either in the broker or your application. Please elaborate on the use-case that leads to this behavior. > ...after some release the name changes, and unused queues are piled up with messages. Can you elaborate on this? What release caused queue names to change? > Some clients can read multicast queue using fully-qualified queue name like "address::queue", other clients cannot... As far as I know, every client should be able to send-to or consume-from the fully qualified queue name. Which clients are unable to do so? > Permissions for the management console are configured separately from permissions on the broker like in two different applications... Messaging and management are logically separate concerns and they operate on different (although overlapping in some cases) resources. > ...there is no way to reload management.xml without restarting the broker. Management authorization will be configured differently in future versions so this won't be an issue. > 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). Using the management console to send a message requires both management and messaging authorization since both kinds of operations are involved. I'm not sure how it could be any different, but I'm happy to hear any suggestions. > And there is no application like IBM MQ Explorer for Artemis. I'm not familiar with IBM MQ Explorer. What does it specifically do that the web console does not? > It is possible to use JMSToolBox only for some scenarios like sending test messages, listing and browsing queues. Sending messages, listing queues, and browsing queues should all be possible via the web console. > 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. There's been a number of improvements to paging in the last several versions which may help your situation although I can't say for sure without specifics. Please open a Jira for any stability issues. If we don't know about the problems then we can't fix them. > Also we did not find a way to restrict the number of messages in the particular queue. Can you elaborate on your use-case here? You should be able to use the max-size-messages address-setting along with an appropriate address-full-policy to limit the number of messages. For any of the items in this email which need follow-up it may be best to create a new thread on the ActiveMQ users mailing list rather than diverting this thread from its original purpose. Justin On Sun, Feb 25, 2024 at 3:57 PM Alexander Milovidov <milovid...@gmail.com> wrote: > 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 <bfz...@hotmail.com>: > > > 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 > > > > > > -- > С уважением, > Александр Миловидов >
