activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: ActiveMQ thoughts
Date Tue, 11 Dec 2007 06:34:55 GMT
Appreciate the honest feeback!


Rob Davies
'Go further faster with Apache Camel!'
http://rajdavies.blogspot.com/


On Dec 10, 2007, at 9:31 PM, 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: http://www.nabble.com/ActiveMQ-thoughts-tp14262131s2354p14262131.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>






Mime
View raw message