ActiveMQ Vs Apollo Vs Kafka


Answer :

Apache ActiveMQ is a great workhorse full of features and nice stuff. It's not the fastest MQ software around but fast enough for most use cases. Among features are flexible clustring, fail-over, integrations with different application servers, security etc.

Apache Apollo is an attempt to write a new core for ActiveMQ to cope with a large amount of clients and messages. It does not have all nice and convenient feature of ActiveMQ but scales a lot better. Apache Apollo is a really fast MQ implementation when you give it a large multi-core server and thousands of concurrent connections. It has a nice, simple UI, but is not a "one-size-fits-all" solution.

It seems that there is an attempt ongoing to merge a number of ActiveMQ features with HornetQ under the name ActiveMQ Artemis. HornetQ has JMS2.0 support, so my humble guess is that it's likely to appear in ActiveMQ 6.x.

JIRA, Github

Kafka is a different beast. It's a very simple message broker intended to scale persistent publish subscribe (topics) as fast as possible over multiple servers. For small-medium sized deployments, Kafka is probably not the best option. It also has it's way to do things to achieve the high throughput, so you have to trade a lot in terms of flexibility to get high distributed throughput. If you are new to the area of MQ and brokers, I guess Kafka is overkill. On the other hand - if you have a decent sized server cluster and wonder how to push as many messages as possible through it - give Kafka a spin!


This is an older question but I'll provide a more modern answer here.

  • The Apollo project is unofficially dead and they suggest Artemis is the new hotness. (link) The (seemingly) stalled development of Apollo does not give me confidence in Artemis's future.
  • My experience is similar to Petter's answer in that ActiveMQ is feature rich and capable. However, it seems as if every release fixes random crashes and memory leaks and this does not inspire confidence. It's stable for my project (which uses clustering) but we have seen weird behavior and crashes in the broker over the last dozen or so releases (currently using 5.14.3)
  • I have not used RabbitMQ (my current project is committed to ActiveMQ) but I will be trying it out on the next project that needs a messaging bus. Not having the kitchen sink of features to support will hopefully mean it is more stable.

EDIT: The 2.3.0 Apache Artemis release happened ~Sept 5 2017. So it does seem to be progressing as of now. But (link) changelog still seems too scary.


I amde a performance benchmark of ActiveMQ, Apollo, HornetQ under non persistent scenario and persistent scenario, I think it will helpful for you to choose which one should be used, the link as shown below: http://hiramchirino.com/jms-benchmark/ubuntu-2600k/index.html


Comments

Post a Comment

Popular posts from this blog

Are Regular VACUUM ANALYZE Still Recommended Under 9.1?

Answer : VACUUM is only needed on updated or deleted rows in non-temporary tables. Obviously you're doing lots of INSERTs but it's not obvious from the description that you're also doing lots of UPDATEs or DELETEs. These operations can be tracked with the pg_stat_all_tables view, specifically the n_tup_upd and n_tup_del columns. Also, even more to the point, there is a n_dead_tup column that tells, per table, how much rows need to be vacuumed. (see Monitoring statistics in the doc for functions and views related to statistics gathering). A possible strategy in your case would be to suppress the scheduled VACUUM, keeping an eye on this view and checking on which tables the n_dead_tup is going up significantly. Then apply the aggressive VACUUM to these tables only. This will be a win if there are large tables whose rows never get deleted nor updated and the aggressive VACUUM is really necessary only on smaller tables. But keep running the ANALYZE for the optimiz
Read more

Can Feynman Diagrams Be Used To Represent Any Perturbation Theory?

Answer : Diagram machinery works also for perturbation theory in classical statistical mechanics and classical field theories. Generally, various kinds of diagrams constitute a pictorial way of talking about tensor products and their contractions while hiding the multi-linear algebra from the layman. In the simplest case, vertices (or blobs) represent vectors, matrices, tensors; vertices have ingoing and/or outgoing ports; ingoing ports denote (contravariant) ro indices; outgoing ports denote (covariant) co indices; directed arcs between blobs give a pair of equal indices summed over; different base spaces ⇔ \Leftrightarrow ⇔ different arc types; symmetric tensors ⇔ \Leftrightarrow ⇔ undirected diagrams; no labels are needed for internal lines. In many cases, the directed arcs are decorated (as thin, thick, broken,wavy, curly lines), each decoration indicating the presence of a so-called propagator, a function of its label to use as a weight in the sum, which may beco
Read more