Please share with the community what you think needs improvement with IBM MQ.
What are its weaknesses? What would you like to see changed in a future version?
We are looking for another solution that is less expensive. There is room for improvement. The live and portal monitoring needs improvement.
At the moment we're very limited in the way we can interface with the cloud.
It could provide more monitoring tools and some improvement to the UI. I would also like to see more throughput in future versions.
The monitoring could be even better by building it into the product. The disaster recovery mechanism could also be built-in. I would like to see them not rely on third-party tools for everything. Finally, they have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like.
IBM MQ has a lot of room for improvement. It's an older solution but they are improving the product. It's wider and it's a heavy application so it supports clusters also. It is expensive. The cost is high. There should be more improvement in the new age of technologies.
You should be able to increase the message size. It should be dynamic. Each queue has a limitation of 5,000. Also, the maximum message length defaults to 4 MB. If it is more than that it should be able to increase and allow whatever the particular size of the message is into the queue. In terms of additional features, I would like to see it be lightweight and go to the cloud easily, and dynamic scaling should be added.
I would like IBM to improve the performance. Right now, it is lacking and can be bulky.
I can't say pricing is good. It is a popular and reliable solution. IBM can be integrated with other products which is why it gets sold. People also like Oracle. They can be integrated with multiple systems. That is a selling point for these solutions.
The worst part is the monitoring or admin, especially in the ACE or Broker. There is always a problem of transparency. In MQ you can observe any process and you know exactly what's going on behind the scenes, but with the ACE or Broker, it's a problem monitoring the HTTP inputs. It's like a black box. The reason that I'm emphasizing monitoring is that I used to work for the company that produced the administration and monitoring tools for IBM. There was a lot of competition and a lot of confusion in the market. When I moved to this company I actually used my previous experience and wrote my own tools. I am not much of a C# programmer, so I was struggling a bit. I know the concepts, but I was missing some straightforward support from IBM. They were selling it as a part of Tivoli, but you needed to implement the whole Tivoli infrastructure. If you had some other monitoring provider it was a bit of a pain. That is my concern here.
We have had an issue with the migration. Most of our applications are running on Java and WebSphere. We have a project to get rid of an old .NET application since we are experiencing a loss in connection during the migration to 9.1. The problem appears to be more on the .NET side than the MQ side though. The technical user interface is outdated in terms of the language used. I think this is inherited from the mainframe. This is more of an engineering issue. It is running on a Windows platform, and I don't like having Windows being the backbone of our company. I don’t like legacy view of MQ.
It could be easier to use.
I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.
They could integrate monitoring into the solution, a bit more than they do now. Currently, they have opened the REST API so you can get statistic and accounting information and details from MQ and build your own monitoring, if you want. IBM can improve the solution in this direction.
I am not involved with it at the architect level. I am providing entry-level support for the product. But perhaps if they could come up with monitoring dashboards that would be good. We are using external monitoring tools, apart from our IBM MQ, to monitor IBM MQ. If we could get monitoring tools or dashboards to keep everything simple for the user to understand, that would be good.
What could be improved is the high-availability. The way MQ works is that it separates the high-availability from the workload balance. The scalability should be easier. If something happens so that the messages are not available on each node, scalability is only possible for the workload balance. That's a big difference. And the application must be prepared to consume from each node so that it doesn't lose a message. Otherwise, you lose the ordering of the messages.
I had some issues earlier, two, three years back. I don't exactly remember them now.
Day-to-day, I don't really see anything much that we are lacking, but I have never really compared MQ with other products to see what it lacks. I am well aware of the way that IBM sells the suite of products. But I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka. One of the other improvements that I would like to see from MQ is for it to be containerized. It may already have that functionality.
The memory management is very poor and it consumes too much memory. We have 24 gigabytes of RAM and almost every day, we had to free up processes so that it can run. Some of our messages were not being transmitted so we had to manually look at the MQ server to cut and paste them. That is supposed to be fully automated. The problem is normally a routing issue but it is compounded if there are connectivity troubles. For example, if 3,000 messages are supposed to be sent but 1,000 were not then you have to do it manually. The solution is not very lightweight and if it could be decentralized, then put into three or four containers, it may be an improvement in this regard.
I would like to see faster monitoring tools for this solution.
* Better testing by the supplier is needed * Ability to send to a group of queues without the need to use pubsub and without the need to write one's own programmes.
I believe there is too much code to be done in order to handle the elements that you develop. We choose a new feature, we would choose something that is a little more … even more out-of-the-box, and gives me the possibility to configure directly where the messages should go, instead. Also, the IBM MQ, it doesn’t really have a connector.
MQ needs instruments for connection with new modern queues like Kafka or RabbitMQ.
There is not much room for improvement, except it could get a face lift with a modern marketing campaign.
SonicMQ CAA (continuous availability architecture) functionality on auto failover and data persistence should be made available without a shared drive, as it exists in multi-instance queue managers.