How does activemq compare to zeromq?
ZeroMQ = wire protocol and library for messaging, ActiveMQ = a message broker.
ZeroMQ is cool from a technology angle. Before considering it though, keep in mind it's LGPL v3 licensed. :(
ActiveMQ: Not ready for prime time
51–60 of 93 posts
Re: ActiveMQ: Not ready for prime time
#52Earlier quoted context omitted.
Hi - this is pretty damning. We're currently building an application that uses ActiveMQ but I could switch to a different broker if I thought it was justified. Do you remember which version you were using?
I believe it was 5.0 and 5.1.
I experienced similar issues with these versions.
Re: ActiveMQ: Not ready for prime time
#53I see lots of questions here about which queuing implementations one ought to consider. Some things to think about:
1. Do you need transactionality? What if your consumer experiences an error after it takes a message off the queue but before it finishes up processing it? Is it ok for that message to disappear forever? The common use case to consider is a consumer which takes a message from a queue, does some processing, and updates a database. To avoid distributed transactions, people often write these consumers so that they check first to see if a message has already been processed. This way, one simply ensures that his DB transaction commits before committing to the consumption of the message.
2. What level of message durability is required? Is it ok for all enqueued messages to disappear when a power cord is inadvertently pulled? I used ActiveMQ to populate a user behavior data warehouse. As users did stuff on a website, the application servers would enqueue observations (went to the product detail page, etc.) and these observations would eventually wind-up in a big Oracle DB. A delay of a day or so didn't matter, but we didn't want to lose more than a fraction of a percent of our observations. So, the queue was in effect a temporary system of record, and we had to allow for reboots, power outages, etc.
3. High Availability. Many modern queueing implementations can be deployed in redundant, scalable "meshes", ActiveMQ included. I haven't kept up on the feature sets of RabbitMQ, JBoss's offering, etc. or I would comment more here.
There are obviously a bunch of other considerations, but these are often the ones which are ignored when comparing ZeroMQ to ActiveMQ, etc. There's no right or wrong answer. "Lighter" implementations are often appropriate for messages where, if the shit hits the fan with your environment, the messages are useless anyway. IIRC, eBay builds pages by firing off a bunch of async requests for page parts, waits a maximum of N milliseconds, and then renders the page based on which pieces made it back on time. There's no value in persistence or transactionality, but the mesh sure better scale up.
Re: ActiveMQ: Not ready for prime time
#54sorta reminds me of the time I built something in 2001 which was a reactive system that was sort of a web crawler but also a bit more... seems demented looking back, but I used qmail as a message queue system for it.
qmail's speed is something that it's rivals still don't have.
Re: ActiveMQ: Not ready for prime time
#55How does activemq compare to zeromq?
zeromq does not persist messages so you can lose them and need to adjust your infrastructure around this. If you are used to network programming that should be fine, just build persistence in to your protocol where you need it, ie reply after you have committed to persistent storage.
ZeroMQ can persist messages to disk in high water mark situations, so once it hits memory pressure it can put it to disk, but it won't read from disk on crash...
Re: ActiveMQ: Not ready for prime time
#56The 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…
RabbitMQ has gotten much better about memory management as of version 2.0.
Re: ActiveMQ: Not ready for prime time
#57I'm not too familiar with the message queue use-case, but perhaps this is something you could do with ScalienDB, which supports replication and failover. Disclaimer: I wrote it.
A message queue is like a database except people can open a socket and say "notify me when there is a new value for this key" -- and you can chose to let multiple people get in line for such updates and then wether you want to let everyone know or just the first person or so-on. you can implement all of this on any db with polling and locks, but that is not an efficient way to do things.
Re: ActiveMQ: Not ready for prime time
#58How does activemq compare to zeromq?
activemq should offer higher level guarantees about reliability. zeromq is simpler. you can argue that activemq has things you will probably end up implementing yourself on top of zeromq, or that zeromq has less to get wrong... 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 reli…
"it uses direct connections between peers" -- this is kind of true.. the guide suggests that ultimately you will want a broker (what it calls "devices") to intermediate producer-consumer interactions.
Re: ActiveMQ: Not ready for prime time
#59Earlier quoted context omitted.
ZeroMQ = wire protocol and library for messaging, ActiveMQ = a message broker.
ZeroMQ is cool from a technology angle. Before considering it though, keep in mind it's LGPL v3 licensed. :(
LGPL means you can link it into your program, so what's the worry?
Re: ActiveMQ: Not ready for prime time
#60lol. At a previous job, I used ActiveMQ. It was definitely a flaky piece of junk.