Systems need to talk to one another. When an IT environment contains platforms with multiple messaging protocols—and most do—a message queue (MQ) is required to handle the messages that travel back and forth. Also known as a message broker or message-oriented middleware (MOM), a message queue is an intermediary application that translates message protocols between the sender and receiver. Message queues are essential for application integration.
This article offers insights into two of the top message queues. According to online reviews by enterprise users in the IT Central Station community, these are IBM MQ and Pivotal RabbitMQ.
What do enterprise users actually think about these message queues? Here users offer a balanced view of their favorite message handling and integration features from each solution while also sharing some thoughts on room for improvement.
IBM MQ
Valuable features
“One of the most valuable features is the standardization in terms of messaging; if you have IBM MQ, you probably can talk to anybody. That’s one thing, its compatibility. The other one is its stability.
MQ has improved my organization in many ways. As I’ve mentioned, it’s sort of the standard in the market. If you use MQ, you probably can talk to anybody in the market. We also use IBM Integration Bus and they integrate well.”
— ITarchitc951, IT Architect Mainframe at a financial services firm
“The multiple queuing features, so that everything that we use for talking to our reservation system, the main system we use it for; whatever systems that are sitting on Linux or other environments such as AIX, and then talking to iSeries, which is our ‘mother ship,’ the reservation system. The most valuable features are being able to handle those multiple queues and being able to scale properly. Before we used IBM MQ, basically it was more of a batch job, sending and receiving messages; kind of like an upload, download type of thing. Now, it’s real time, where we can effectively handle millions of transactions an hour, once we implemented MQ.”
—Alfred M., IT Infrastructure Manager at a leisure / travel company
“We use it right now for transferring a lot of big files. Sometimes, for some reason, the file doesn’t get all the way to the other side. We do it between different cities. IBM MQ keeps track of it and gets it all done. We at least know if it was half-done or not. We also have scheduled jobs through ESB, but it doesn’t send that kind of notification to us. It says whether the script has run or not run. That’s all we get. This has been a better product. Besides that, we do a lot of our jobs through it. We queue them and run them. These files are critical. They have to reach the whole file. Sometimes, a half file gets the same name and gets processed as a half file. The result is like replenishing all those files. The results are really screwy if you get half files. Since we started using MQ, we haven’t seen this.”
— technica1186, IT Architect at a retailer
Room for improvement
“They might be able to improve the monitoring features. When you’re looking at distributed platforms, you’re looking at different breakpoints to it. IBM MQ has a good support structure, but it would be nice if they could kind of fold MQ into other tools to make it more resilient for other tools, other relationships, and other non-IBM platforms. That’s probably the strongest piece: being able to support the other customers. Eventually, if we can support them end-to-end and tell them where their problems are, we can bring them into our fold and make it an IBM fold.”
— seniorpr5a3d, Senior Project Manager, Infrastructure Delivery at a hospitality company
“It would be nice to see it outside of the z/OS environment, I think. If there was any other type of standalone client application, that’s something that I would be interested in. It’s within z/OS, so it’s green screen. It’s not user friendly, but I can understand that. I’ve had the training to be able to look at it. It definitely could be improved, but within z/OS, you know you’re not going to get any type of color graphical interface.”
— associat5eb1, Associate Software Engineer at a financial services firm
“With the tooling around being able to see what’s in the queue, we found third-party products to be friendlier than the out-of-the-box products, as far as, “Let me see what the content is of the object that’s on the queue.” I want to actually be able to see what’s on the queue, and the tools we were given from IBM or from the representatives were terrible. I guess that would be the thing I’d like to see. I’ve got the third-party products that I use now and it’s at the operating-system level, but that would be the suggestion.”
— technicaf3c7, Application Architect Lead at a retailer
Pivotal RabbitMQ
Valuable features
“We find authentication, performance, and durable messaging the most valuable features. Due to the nature of my use case, performance and security were of the highest priority and were the main reason I chose RabbitMQ messaging frameworks. Over time, the most useful feature became the ability to create durable queues, which increased reliability and also boosted performance.”
—ThomasS346, Senior Application Developer at a software R&D company
“RabbitMQ is good in its real-time capability of delivering the sensor data in different topic abstractions. It is quite easy to set up in our sensor network system which involves data monitor agents across geographically distributed organizations. This tool made our research process easier and allowed our administration (monitoring) process to happen at the same time. We created different queues for different use cases of the same streaming data.”
— GraduateTA901, user at a university
“Valuable features include queues and topics, native cloud app support, lightweight and easy maintenance, simple and straightforward admin portals, which made it easy for users and worked out excellently for our requirements. My company runs on high availability. It is known for high accuracy in its items that are being shipped. To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy. Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create ‘queues’ on the fly and pass messages from one system to another.”
— Developmeb7c, Development Lead, Java/Hybris at a consumer goods company
Room for improvement
“Improve the ability to handle the large message load. People usually use RabbitMQ as the lightweight messenger; if they have a large message load people are inclined to use Kafka. But at the beginning stage of most projects, the data is small, people do not need to use a Kafka type of messenger, they are more likely to use RabbitMQ. If RabbitMQ can handle the large message load and support ordered delivery, with the project growing, data bigger, people can still use RabbitMQ and wouldn’t need to find another tool to use like Kafka which is much more convenient.”
—ResearchAsst939, Data Scientist at a university
“RabbitMQ is great, but it depends on the Erlang VM. I understand that Erlang is the reason why RabbitMQ is what it is. However, having to install and maintain yet another VM product has been annoying. The configuration for RabbitMQ borders on the esoteric. Once we got all of the moving parts working, it’s been a dream. However, it was an effort just to get it going.”
— Robert H., Director of Information Technology at a transportation company
“The biggest area we struggled with was operations troubleshooting. We were running a pretty big cluster and ended up with some random cluster failures that were difficult to troubleshoot. A good portion of these were self inflicted but occasionally the distributed database would end up corrupted.”
— VpOfSoftb75e, VP of Software at a manufacturing company
Read more in-depth real user reviews about these and other message queue solutions by downloading IT Central Station’s Buyer’s Guide for Message Queue.