21–30 of 93 posts
I can't believe the ActiveMQ/FuseSource guys weren't willing to work it out with David either. Perhaps there's a bit of open source/commercial software wrangling behind this story. Won't be the first/last time.
I used ActiveMQ in a large production environment for two years. It's by a large margin the worst piece of software I've used professionally. You wouldn't believe the number of very serious problems we had with it (including some mentioned here, like negative queue lengths, but mostly broker crashes, missing or wrong documentation, outright broken features, serious threading issues, and poor performance). If anyone's…
How does activemq compare to zeromq?
another way of saying the same thing, which illustrates the cultural differences:
- activemq is intended to be used in "the enterprise". it tries to implements a logical ideal, which is a reliable infrastructure that services can use without being coupled to each other - without worrying about whether messages were received, or exactly who they go to. to reduce complexity it uses a central broker (so you send messages to a central "hub").
- zeromq is intended (imho) for programmers that want to wire things together. it's less concerned with abstractions and more with providing something simple clear, simple and flexible that can be understood and used well. to reduce latency it uses direct connections between peers.
from that viewpoint, you can see that the two are both orthogonal and yet similar... (disclaimer: i haven't used either, but i used work on an ESB so have a vague grasp of what's going on. please someone correct me if this is wrong - i might as well learn as i lose karma ;)
ps rabbitmq is somewhere in the middle and was (i think) originally more performance-motivated (i believe it's used in finance for example - when speed might be critical).
The thing I've found about message queues is that it's pretty unimportant what platform they're based on. I used to be tempted to go with ActiveMQ "because it runs on the JVM", but that turns out to be pretty irrelevant. No matter what your queue provider, you're most likely just using TCP sockets anyway, so don't think you need to be using Erlang just to take advantage of RabbitMQ. Yes, this means the MQ can basical…
What I've seen with RabbitMQ is that the memory usage can grow and grow. If it runs out of either committed RAM or address space, it crashes. I suspect this may be a feature of the open source Erlang VM that's improved in the pay-for-support version. Even though RabbitMQ pays the performance cost of bouncing everything off the disk, it's not quite recoverable from that type of crash. I'm sure my information is old, p…
The thing I've found about message queues is that it's pretty unimportant what platform they're based on. I used to be tempted to go with ActiveMQ "because it runs on the JVM", but that turns out to be pretty irrelevant. No matter what your queue provider, you're most likely just using TCP sockets anyway, so don't think you need to be using Erlang just to take advantage of RabbitMQ. Yes, this means the MQ can basical…
What I've seen with RabbitMQ is that the memory usage can grow and grow. If it runs out of either committed RAM or address space, it crashes. I suspect this may be a feature of the open source Erlang VM that's improved in the pay-for-support version. Even though RabbitMQ pays the performance cost of bouncing everything off the disk, it's not quite recoverable from that type of crash. I'm sure my information is old, p…
> It's not correctly configured out of the box. You mean there's a correct configuration? Also, Tomcat, Jetty, PostgreSQL, and Ngnix don't "install correctly" out of the box as described here. Tomcat clusters set themselves up? Postgres? Hell, I think default shared buffers allocation is 32 MB... > Anything that streams bytes I'm not sure what the author is trying to do. Doesn't sound like queuing to me... The docume…
The part about Tomcat certainly isn't true, unless the author is using a different distribution than what you get from the project's website. The Tomcat startup scripts do not set any heap size paramters; until recently the default Sun JVM behavior was to set a max heap size of only 64MB. This logic changed a few versions ago to use a fractional amount of the total memory size on the machine, but for dedicated hosts…
That it's not production ready is pretty big claim. I don't want my clients reading this and getting all jittery on me.
> It's not correctly configured out of the box. You mean there's a correct configuration? Also, Tomcat, Jetty, PostgreSQL, and Ngnix don't "install correctly" out of the box as described here. Tomcat clusters set themselves up? Postgres? Hell, I think default shared buffers allocation is 32 MB... > Anything that streams bytes I'm not sure what the author is trying to do. Doesn't sound like queuing to me... The docume…
Well, if every piece of enterprise software worked right out of the box, consultants would be out of business. I have to admit that I'm not a big user of ActiveMQ, but I've used a closed-source equivalent from a slightly bigger vendor (IBM) for many years. It also is not configured correctly out of the box for most enterprises. When new features or platforms come out they are often buggy. The documentation though is…
Excuse my ranting -- I'm a middleware system administrator and WMQ is the necessary evil at my workplace.
One thing I remember in particular from ActiveMQ was that it would often get itself into the state of having negative queue lengths.
I used ActiveMQ in a large production environment for two years. It's by a large margin the worst piece of software I've used professionally. You wouldn't believe the number of very serious problems we had with it (including some mentioned here, like negative queue lengths, but mostly broker crashes, missing or wrong documentation, outright broken features, serious threading issues, and poor performance). If anyone's…
I used ActiveMQ in a large production environment for two years. It's by a large margin the worst piece of software I've used professionally. You wouldn't believe the number of very serious problems we had with it (including some mentioned here, like negative queue lengths, but mostly broker crashes, missing or wrong documentation, outright broken features, serious threading issues, and poor performance). If anyone's…
Why'd you write one from scratch instead of just using JBossMQ or HornetQ or something? ActiveMQ is far from being the only open-source message queuing product, even if you only consider JMS compliant ones.
I just found a thread I started about ActiveMQ and scaling:
http://activemq.2283324.n4.nabble.com/6000-ActiveMQ-clients-...
Note the last message there. 36,000 threads when using NIO! And these answers were from the people commercially supporting ActiveMQ (FuseSource). I never did find out (on that thread or elsewhere) whether ActiveMQ has ever been used in a situation that large. I suspect it hasn't.