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


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.