Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <14295525.post@talk.nabble.com>
Date: Wed, 12 Dec 2007 05:59:32 -0800 (PST)
From: Hellweek <bwinslow@tfutures.com>
To: users@activemq.apache.org
Subject: Re: ActiveMQ thoughts
In-Reply-To: <14285042.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <14262131.post@talk.nabble.com> <14285042.post@talk.nabble.com>


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: http://www.nabble.com/ActiveMQ-thoughts-tp14262131s2354p14295525.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.