08 July 2011

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:

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.

The Fiorano Team


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:


They even tweeted about it:


(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


  1. Hi Bruce,

    I recently measured CXF performance with http and jms. When the configuration is tuned for performance ActiveMQ is not much slower than the less reliable http transport. This much about poor performance. :-)

    What I can confirm though is that ActiveMQ with default config was quite slow.

    See http://www.liquid-reality.de/x/WoBZ


  2. @Christian, that is not an uncommon situation. I would tend to differ slightly with Bruce's opinion that the out-of-the-box configuration is what a developer would use, not production or even middle of the road. Have a look at Tomcat or JBoss implementation that is out of the box. Is that production ready? No. What about an Oracle database? That most certainly is not production ready after you download it. This is common to have a watered down configuration for first use.

    @Bruce... awesome blog post. This situation reminds me of the MuleMQ debacle that claimed better performance than ActiveMQ. That certainly got them nowhere ;-) Love the Ghandi quote... its spot on.

  3. Some vendors are great, they participate in open source (even if they don't make decisions everyone agrees with all the time). Others just sit there and snipe at other projects.

    I've had a lot of experience have to stand by negative statements, and I can tell you that the person that wrote this particular hit piece on ActiveMQ wasn't experienced enough to understand that putting that many negatives together in one place is creating a awful lot of negative message to attach to your own product pitch.

    If you really want to convince someone that a particular project has issues that your product addresses you can't just barge into the party, guns blazing, and start dealing out damage. Instead you have to build it up as an objective comparison. (See the introduction in the Maven book about Ant. Am I coming out and saying "Ant is awful sauce."? No, I'm like Ant's cool, Maven's cool, I think Maven's cooler."

    But, in summary, some vendors are bottom feeders and this one sounds like just that kind of vendor.

  4. I don't normally defend ActiveMQ, however....

    When I was working at Red Hat, we did a systematic performance comparison of all the significant JMS brokers on the market, including Fiorano.

    Although Fiorano had good non persistent message performance, it was clear they were cheating with their persistent message performance.

    The disks we were using had hardware write cache disabled, and could physically do about 300 syncs per second.

    Therefore with a single JMS persistent producer it should not be possible to send more than 300 messages per second. However Fiorano managed to send many more than that per second.

    This meant they were either a) defying the laws of physics b) cheating.

    My guess is it was b).

    So it's a bit rich them complaining about ActiveMQ reliability!

  5. Anyone writing something like that should support it with actual findings. Something like that should be considered a joke really.

    I doubt anyone will buy any services from that provider based on that letter.

    +1 for Tim Fox

    BTW: The IT world is a small world (even smaller if you subset it to the messaging industry). I really think anyone should always treat competitors with respect and fair competition.

    Fair competition is actually health for the industry. I'm currently leading HornetQ and I try to professionally compete on this market.

    Tim Fox used to be the leader on HornetQ and he's still highly respected by anyone I know.

    What will happen to the guy who wrote this if he ever gets out of Fiorano?

  6. Blogger seems to be acting weird again with comments. It's a good thing that all posted comments do seem to get emailed to me successfully. Anyway, I'm manually posting this comment that was posted twice but for some reason is not showing up:


    Hi. This is Vaibhav Bansal, marketing communications, Fiorano. The message on ActiveMQ was sent out to all Fiorano-registered website visitors.

    The information in the message is based entirely on feedback from real customers and prospects who are current ActiveMQ users actively looking to make a change.

    Given the fact that this mailer was to go out to thousands of registered Fiorano visitors, it was not possible to include very detailed information about each point. We apologize for that.

    Here are a few points:

    1. Performance - please see the whitepaper at http://www.fiorano.com/docs/jms_performance_comparison.pdf. The tests used to evaluate performance were developed 9 years back by Sonic Software and the source code is available for you to run the tests yourself. If your development team wishes, we will be happy to send them the source code, together with scripts to run the tests. Please send me email at vaibhav.bansal@fiorano.com if there is interest. The tests show that ActiveMQ is significantly slower than commercial JMS vendors for persistent queuing, among other things. ActiveMQ is, however, relatively fast for non-persistent messaging, especially queuing.

    2. Stability, etc. : This was a consistent report from large end-users, some of whom have recently moved to Fiorano (and other commercial vendors). It may be a good idea to talk to your customers in more detail about these issues since they would be able to provide you with with more feedback regarding configuration etc. that you have mentioned as solutions for this problem.

    3. Documentation : As you have already acknowledged, the ActiveMQ documentation is not the best. Plenty of scope here for open-source developers to add more, I'm sure you'll all agree.

    4. Inadequate Technical Support : the complaint from enterprise-customers was that the support quality was very inconsistent and at key moments, high-quality support was not available even though paid for. Telephonic support was sporadic and unreliable and compounding this issue was the fact that information was difficult to locate in the ActiveMQ Documentation . Again, this is an area where the ActiveMQ team management can better engage with users and support providers to get feedback and try to improve things if needed.

    5. Inability to handle Peak Loads : This was mentioned by some financial services customers; they also said that "slow subscribers" were not handled well at all. My understanding is that this issue is fairly subtle and therefore may have been missed by the ActiveMQ development team.

    6. Scaling only with new Hardware : This was mentioned in the same context as item 2. Clustering obviously does not lead to linear scalability.

    We would like to reiterate again that the facts above are from real-feedback from existing ActiveMQ users. It is clear that many of these customers need better support and likely more consulting work to tune their middleware better - a great opportunity for all ActiveMQ developers.

    Vaibhav Bansal,
    Fiorano Software, Inc.

  7. @Vaibhav, thank you for your comments regarding this topic. Please allow me to respond:

    Certainly Fiorano has its reasons for publishing this letter, but IMO this is just simply an attempt to gain customers through the use of hearsay and FUD. It's one thing to publish a letter that is based on facts with actual proof to back up each one of the points. It's a completely different thing to publish such a letter that is not based on fact that relies upon nothing but hearsay. You even admit that the information in the letter comes directly from ActiveMQ users -- and we know that they always configure ActiveMQ correctly and never make rash decisions based on emotion.

    Regarding your testing, based on your lack of knowledge of ActiveMQ, I'm sure that there was zero configuration change to ActiveMQ for your tests. If the tables were turned, I'm pretty sure that I wouldn't be able to tune Fiorano MQ for the situation either therefore causing it to have a bad showing in comparative testing. This is a long-tired argument where one vendor is testing multiple competing products and only tuning their own product.

    Your reasons for this letter do not convince me to change my opinion of the letter. In fact, your admission that it is based on hearsay causes me to remain steadfast in my opinion.

  8. Yet, is the claim that activemq is not linear scalable true?

  9. @brio, NO, the claim that ActiveMQ is not linearly scalable is not true at all. It's simply a matter of knowing how to tune the message broker for the situation (and/or tweak the app design). I've performed this task many times for consulting customers, so I know first-hand that this is untrue.