On 10/12/2007, Hellweek <[EMAIL PROTECTED]> wrote: > > > Hello, > > I know what I am about to post will upset a few people, however I think it > is important that I document my experience with ActiveMQ in the hopes that > others like me can have an understanding of the issues that you will face. > > A little history. > > I am not new to Open Source projects, have been involved in them and have > sponsored the use of open source for many years. > > I have been working with various message brokers for a few years. My first > experience was with TIBCO EMS. Needless to say I was very impressed with > the stability and functionality of this fine EMS. Next I had the > opportunity to work with Sonic EMS. Again I was impressed with this product > and was even happier with its low cost of ownership. > > Over the last 6 weeks it has been my job to evaluate for our Trading firm an > internal messaging system. We wanted to use a EMS solution for > dissemination of pricing data to our in-house applications as well as > external clients of ours. The messaging systems we are evaluating. TIBCO > EMS, MSMQ 3.0, SONIC EMS, ACTIVEMQ 4.1.1 or ActieMQ 5.0. > > How did each product fair? > 1. Tibco EMS no issues with any of the stress tests and performance tests. > 2. MSMQ don't even get me started with this POS. > 3. SONIC EMS no issues with any of the stress tests and performance tests. > 4. ActiveMQ can not make it past any stress tests. See issues below for an > understanding of what we saw. > > > I have watched ActiveMQ for well over 2 years and 2 years ago the project > was so filled with issues that I knew I would never be able to recommend it > to the owners of the company. 2 Years later and I was in the position of > trying ActiveMQ again and hoping that it would be stable. > > I was very pleased to see that many of the issues I saw with ActiveMQ had > been resolved and was committed to giving ActiveMQ a chance at being our EMS > solution for the future. However, I can say after weeks of testing ActiveMQ > Is still not ready for production use by myself and the firm I work for. If > you have high message throughput with high number of subscribers ActiveMQ is > not well suited for your needs. > > Lets take some time to examine the issues. > > CPP ActiveMQ Client > 1. A fast producer with slow clients can and will take down the producer. > From what I have seen in testing a slow client can bring the producer down > and in some cases can bring the broker down. A miss-behaved producer or > client should never ever take the broker down. > > 2. A Producer that producers more then 200 messages per sec locks up the > Broker when the Broker has only one client connected. This one was the > biggest issue to accept and the one issue that caused us to say ActiveMQ is > not ready for a production environment. The most basic and simple task of > the Message Broker is not working as expected and makes the ActiveMQ > unusable in a environment where peak message Generation can exceed 200 > messages per second. To be honest we never even get close to 100 messages > as it seems we die after 50 messages are fired in the same second. The only > time I am able to have producers producing without locking up or crashing is > if I don't have any consumers listening. Having a messaging system that > works without consumers is not a valid solution. > > Again important to note. As long as no consumers are connected I can > produce massive amounts of messages. Once you connect a client massive > issues start to happen. > > 3. Producers and consumers created on the same connection can cause > deadlocks. This is a major issue and the main solution is to not do this. > However, this is an unacceptable solution as it is my understanding this is > an acceptable practice. > > 4. A fast producer with a fast consumer leads to resource creep. I don't > want to say it is a memory leak because it is not a leak it is just a very > very slow release of the memory. I should not have to put sleeps in a > program just to insure that memory gets released correctly. In my test I > had to sleep for 20 MS between each message being sent to keep the ActiveMQ > consumer running. > > 5. Placing a breakpoint on the message listener on a consumer will cause out > of memory errors in the producer. Why me setting a breakpoint on a consumer > can cause the producer to throw an exception is unacceptable and leads me to > think that a slow consumer can and will take the broker and or producer > down. > > 6. Very confusing to determine what version of ActiveMQ will work with what > version of the client. Example ActiveMQ 5.0 was released this week. > However, no new client was released and no information on when new client > will be released. The CPP client just released a 2.1.3 version that claims > it should be paired with 4.1.1 of the ActiveMQ broker. Where is the CPP > client that is to work with the new features of 5.0? > > With all the issues I have I will not be able to go to a production > environment with ActiveMQ, this is a shame as the people that have been > working this project are talented people and should be commended for the > work that has been done.
Great feedback thanks! I'd be interested to know how ActiveMQ 5.0 fairs once its released (in the next couple of days hopefully) - quite a few of the issues you mention are specific things that were targeted in 5.0 (better flow control etc). -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
