Commercial Vendor Spreads FUD About ActiveMQ

It has come to my attention that a particular commercial integration and messaging vendor is actively spreading FUD about ActiveMQ.

In an official letter that was sent out yesterday, this vendor called out numerous aspects of ActiveMQ, claiming that each is a problem with ActiveMQ and their product 'resolves all of these issues'. Only one of the items mentioned in the list holds any merit. So let's first take a look at the letter and then I will address each item in turn:

Here is the official letter that was sent by the company's media relations:

============================================================
<quote>
From: Fiorano Software
Date: Thu, Jul 7, 2011 at 6:22 PM
Subject: Graduating from ActiveMQ for Enterprise Class Messaging

Dear Joe ,

If you are an ActiveMQ user, you may very likely be experiencing some or all of the following issues:

1. Poor Performance or limitation on speed - particularly for persistent queues and topics.

2. Stability issues or loss of messages, specially with clustering enabled.

2. Poor Documentation - difficult to quickly find what you're looking for or even with paid support you are unable to troubleshoot the problem.

3. Poor Reliability - when a broker goes down, do clients auto-reconnect when the broker comes up again?

4. Inadequate Technical Support - No clear directions/answers from Technical Support - for instance, if you wish to perform memory tuning, do you get clear instructions promptly?

5. Inability to handle "peak loads" - when there's a peak-load condition, does the broker tend to fail?

6. Scaling only with new hardware?

FioranoMQ resolves all of the above issues. With Fiorano, you have the best performance in the industry (for both queues and topics, persistent and non-persistent), responsive and accurate technical support, proven reliability, solid documentation and enterprise-class scalability — all of which adds up to dramatically reduced development and deployment times, with a maintenance cost lower than that of ActiveMQ and other open-source offerings.

To get started, download FioranoMQ now, at http://www.fiorano.com/downloads/login.php?prod=fmq
or contact us via email or phone to get more information.

Regards,
The Fiorano Team
info@fiorano.com
+1-408-354-3210
</quote>
============================================================

Just so you are clear, I did not write this letter. It is an official message sent out by the commercial integration and messaging vendor. Not only has this vendor posted the message on their website:

http://www.fiorano.com/newsletters/ActiveMQ_Issues_July_2011.html

They even tweeted about it:

http://twitter.com/#!/FioranoGlobal/status/89193558032134144

(Yes, I know those are not live URLs. I refuse to provide a live links to be picked up by the Google spider.)

So now let's walk through each point in this message, providing some discussion as we go.

Claim #1: Poor Performance or limitation on speed - This is rather broad statement and I'm sure that's on purpose. The idea when spreading FUD is to be as broad as possible. This way your statements can act as a catch-all for any problems that a user might be experiencing and loop them in based more on emotion rather than fact.

ActiveMQ can certainly provide poor performance if it is not configured correctly. You can do the same with any software that is not configured correctly. From time to time, I have dealt with performance related issues with ActiveMQ on consulting engagements. As I comb through configurations and code to take a look at a situation, many times I find that either the broker or the client are not configured correctly or there's something about the user's code or application design that plays into this scenario. Occasionally a user has asked about providing a better configuration out of the box for ActiveMQ to address a given problem. The answer is that we already do -- ActiveMQ distributions provide a configuration out of the box that should support middle of the road use cases. Problems arise with specific use cases or in a specific environment, etc. There are far, far too many use cases to provide a single configuration that will work with anything anyone might ever dream up.

Claim #2: Stability issues or loss of messages, specially with clustering enabled. - Loss of messages? Really?! Do you think if ActiveMQ actually lost messages that it would be as popular as it is? But blaming the clustering is ingenious for one single reason -- most users don't know enough about the ActiveMQ clustering that they are apt to believe that this claim is true. The only scenario where a user might perceive that messages have gone missing is one where messages get stuck on a particular broker in the cluster. Again, configuration plays a big role in getting clustering set up correctly as does proper application design.

Claim #3: Poor Documentation - This is the only claim that holds any truth, but it's only really half true. The ActiveMQ documentation is certainly lacking. However, the ActiveMQ website does hold a wealth of information. The real problem with it is finding what you need. Although some vendors who provide support for ActiveMQ have attempted to provide improved docs (e.g., notably the documentation for the Fuse Message Broker). This is exactly why Rob, Dejan and I wrote a book about ActiveMQ titled ActiveMQ in Action. We're quite proud of the book because it does provide markedly better documentation for ActiveMQ. If you need better info on ActiveMQ, pick up a copy.

Claim #4: Poor Reliability - when a broker goes down, do clients auto-reconnect when the broker comes up again? - This particular claim makes it clear that this vendor has little to no knowledge of ActiveMQ. This is exactly why the ActiveMQ failover transport was created. In short, the failover transport provides a JMS client automatic reconnection in the event that an ActiveMQ broker goes down or just becomes unreachable. The failover transport is extremely configurable in order to deal with many different scenarios including the ability to delay the initial reconnection, to set a max number of reconnect attempts, to exponentially increase the wait period between attempts and much more. In the ActiveMQ 5.4 release, the failover transport introduced a new feature to provide automatic cluster updates and broker rebalancing to JMS clients. The failover transport is highly powerful and strongly recommended, so I'm surprised that this was overlooked.

Claim #5: Inadequate Technical Support - Based on the vendors listed on the ActiveMQ support page, there are now at least five companies providing support for ActiveMQ. And I even know of a company that provides support which is not listed there, Savoir Technologies. If you are paying for ActiveMQ support and you are not happy, I encourage you to either speak to your vendor about it or find one that works better for you.

Claim #6: Inability to handle "peak loads" - This is a claim against ActiveMQ that I have never once heard from a user. They are essentially asking you if at the time where your business experiences a spike in the amount of messages it is handling, does ActiveMQ fail on you. Yet again, if you are truly experiencing this, then you need to take a serious look at your system design. I have helped many customers successfully address issues of scale through a number of means including some intelligent sharding of JMS client connections across a cluster of ActiveMQ brokers, use of a virtual IP address and even use of a load balancer. If ActiveMQ had a habit of failing for users during peak loads, I would have heard about it at least once.

Claim #7: Scaling only with new hardware? - This claim is similar to claim number 4 and really makes it clear to me that whoever compiled this list is not familiar with ActiveMQ. Did they bother to search the ActiveMQ site? Here is just one page on the site from the FAQ titled How do I configure 10s of 1000s of Queues in a single broker ?. Furthermore, Rob, Dejan and I clearly explain how to scale ActiveMQ both vertically and horizontally in our book. Again, this really depends on the situation and the environment, there is no single silver bullet solution.

Addressing each of these claims was actually quite easy for me to do. And I hope that each of the vendors providing professional consulting services and technical support for ActiveMQ are aware of the tactics being used by this commercial integration and messaging vendor. It sounds to me like ActiveMQ has become a real threat to this vendor's business.

I will leave you with a quote:

"First they ignore you, then they ridicule you, then they fight you, and then you win."
— Mahatma Gandhi