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 jcarlson@e-dialog.com
 designates 208.94.20.29 as permitted sender)
From: Josh Carlson <jcarlson@e-dialog.com>
To: "users@activemq.apache.org" <users@activemq.apache.org>
Date: Sat, 11 Jun 2011 09:57:14 -0400
Subject: RE: ActiveMQ Production worthiness
Thread-Topic: ActiveMQ Production worthiness
Thread-Index: AcwoCcqBW8xge1iYQ+CG86Fahs39vAAMXrA7
Message-ID: 
 <3A2A0F51850C264790C6008B7F92D0470BC56FF021@eeyore.ad.e-dialog.com>
References: 
 <BANLkTimFj8upr1DiieXnNOzSofv9bc3yBg@mail.gmail.com>,<4DF31A0D.9000906@tweakers.net>
In-Reply-To: <4DF31A0D.9000906@tweakers.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

We have been using activemq in production for about a year now. We use pers=
istant messaging and shared file system master /slave for high availability=
 (don't forget to enable tcp_keepalive) and use STOMP. Sparse documentation=
 is my largest complaint. I purchased a $25 doc from some private company a=
nd this got me through the configuration. Sure it was not an out of the box=
 install but there are many use cases and it is highly configurable. We had=
 issues where the JVM would slowly grow in memory (think I saw it as high a=
s 20GB) and would crash about once a week. But a slave correctly failed ove=
r so it wasn't a huge issue. What was an issue is when AMQ would get into a=
 failure condition like running out of file descriptors (our system was onl=
y allowing 1K ... simple fix). Ideally I'd like for it to just exit so a sl=
ave can try to pick up the work. Eventually we leaned that we needed to mon=
itor the queue operations and if they failed to kill -9 it so it would fail=
 over. Then we ran into some scaling issues as we deployed more clients, we=
 discovered that was due to the way our applications were constantly subscr=
ibing/unsubscribing from different queues (there are synchronize blocks in =
that code!). So we changed our client to not do that and since then AMQ has=
 been 100% stable. Since most of our issues were due to the way we were usi=
ng it and frankly the frequent subscriptions was clearly a poor design choi=
ce, its was our fault not so much AMQ's fault (though work could be done so=
 its not serializing there). Would also like to see a warning about doing t=
his on the web page so others don't run into the same issue. But all in all=
 I am a happy user.

Also he people on this list are also very helpful and always seem to respon=
d fairly quickly to questions on this list.

-Josh

________________________________________
From: Arjen van der Meijden [acmmailing@tweakers.net]
Sent: Saturday, June 11, 2011 3:32 AM
To: users@activemq.apache.org
Subject: Re: ActiveMQ Production worthiness

First off, I wouldn't call "< 10k/minute" low volume (unless its also <
1k orso), but that's a matter of opinion. I think my peak of about 10k
messages/minute constitutes of a "relatively high volume".

At least on the comment of not being able to run out of the box... it
did for me every time and version I tried. And we run almost all pub/sub
messages in its durable storage.

And yes, we ran into issues with our very high connect/disconnect-rate.
But that isn't exactly how you'd normally use the software and can be
configured since some 4.x version (although I don't know how well that
flag is documented).

Neither postgresql nor tomcat are necessarily in a production-ready
state with their default install. Postgresql will run, but will likely
require tuning for optimum performance. Although that obviously depends
on the dataset, query-load and query-types used.
Tomcat has the same issue with heap size, simply because that's a
java-issue, not tomcat or activemq. For any jvm-instance there will be a
use case where the default heap size may not be adequate for either the
amount of memory it will allocate or for optimum performance.

I wouldn't run tomcat or postgresql with "<10k queries/pageviews per
minute" with the default install, unless its really much less than 10k.

The other issues I leave to other readers of this list.

Anyway, I'm at least one of the (rare?) positive users of ActiveMQ. I
actually did a evaluation of what was available at the time (some 3-4
years ago) and everything was either (much) slower than ActiveMQ,
couldn't be connected to from PHP (we use Stomp now) or I couldn't get
it to work... So basically all his negative points on the
ActiveMQ-setup, I had that with other message queues ;-)

But we haven't tried HA yet, so we may run into issues with that. We'll
see, I'm not going to put ActiveMQ aside because someone rants about it
and claims he cannot find any positive users of it (see his follow-up,
its even more negative).

Best regards,

Arjen

On 11-6-2011 1:14 Ravi wrote:
> We are considering ActiveMQ for production and somebody pointed to us the
> following link. Anyone comment on the  issues pointed out here ?
>
> http://goodstuff.im/activemq-not-ready-for-prime-time
>
>
> Thank you
> Ravi
>=