activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hellweek <>
Subject Re: ActiveMQ thoughts
Date Wed, 12 Dec 2007 20:13:15 GMT

Well my first impression was wrong also.  I was assuming it was an issue with
C++ and the broker.  However after extensive testing I am sure it is a
problem with interop with C# and C++.  I would hope you dont run into this

I did get to testing C# to C# and I let it run full speed for over 3 hours
sent and received more then 5 Million messages and it performed very well.

For me that test was convincing enough to me that I am holding off on my
Recomendation document.  I am hoping that this is a fast easy fix.  If it is
I think I might just be able to still use ActiveMQ in production.

yg_cvg wrote:
> Ah, I see.  That's different from the impression I was initially getting
> from your post.  In particular, our clients would be Java servlets, so we
> might not run into these issues.  I am in the process of making some
> stress tests myself right now.
> Hellweek wrote:
>> Here is what I can say.
>> With the exception of the issue that I have posted about here I can tell
>> you that I am very happy with the performance of ActiveMQ.
>> As our applications depend on some for of MOM all of our applications use
>> a common MessagingLayer.  As such it took very little time for us to
>> create this layer and instantly have our applications use it.
>> I can tell you that the ActiveMQ is much faster then our existing MOM as
>> such I was very excited about the possible improvments to performance.
>> I think the issue I am reporting here is more an issue with
>> Interoperability between C++ and C#.  At least thats what it is looking
>> like.  A problem has been opened for this issue.  This is a very positive
>> sign.
>> However, I can tell you that you should invest the time in exploring
>> ActiveMQ.
>> yg_cvg wrote:
>>> I am personally watching this thread with great interest, as we're
>>> considering using ActiveMQ for a big highly distributed network, but we
>>> have no idea how it would perform in such a setting.
>>> Hellweek 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.  

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message