4 ms·

RabbitMQ has some pretty serious limitations related to it being implemented on Erlang that keep it pretty strictly in the realm of being a message queue rather

RabbitMQ has some pretty serious limitations related to it being implemented on Erlang that keep it pretty strictly in the realm of being a message queue rather than a generic queue. CouchDB is more C++ than Erlang these days, bad example. It hasn't been mostly Erlang for a really long time. Erlang basically only does the clustering behavior, which is something Zookeeper et al. do already. Riak is the only solid example out of those you listed, and its known for having poor raw performance, excellent availability, easy clustering, and awful usability.

calibraxis 14y ago
> RabbitMQ has some pretty serious limitations related to it being implemented on Erlang that keep it pretty strictly in the realm of being a message queue rather than a generic queue. Interesting, where can I learn more about this claim? What are the incompatible facets of a generic queue and Erlang? What is an example of these generic queues (or if it's only an ideal, what are its characteristics)?
- codewright 14y ago
  Just don't use it for big, long-lived work queues and you'll be fine. If the queue gets badly backed up, you're probably fucked. Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.
  - philsnow 14y ago
    > If the queue gets badly backed up, you're probably fucked. Isn't that true of any queue ?
    - codewright 14y ago
      Not really, no. Depends on what how narrow you are about the definition of "queue".
  - klibertp 14y ago
    I got curious and googled a bit, here's what I found: http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-messaging-with-good-query-features http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-fo... Where the first answer states that: "RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general." (It's contrasted with Kafka, which is "designed for holding and distributing large volumes of messages") Still, I see no reason why you say that it's Erlang that causes this?
    - codewright 14y ago
      People often use Erlang primarily for the memory model. Pure in-memory didn't work for our use-case. You can implement a queue that works better for batch work in Erlang, it's just that it'd be closer to a data store.
klibertp 14y ago
I only said it is being used, not how good the products are... And CouchDB is a perfect example - from what I saw they use Erlang for what it's good at and use other tools where it's not appropriate - that's exactly how Erlang should be used[1]. [1] Or at least Joe Armstrong says so in his book, "Programming Erlang".
mietek 14y ago
> its known Can you point to any references?

calibraxis 14y ago

> RabbitMQ has some pretty serious limitations related to it being implemented on Erlang that keep it pretty strictly in the realm of being a message queue rather than a generic queue. Interesting, where can I learn more about this claim? What are the incompatible facets of a generic queue and Erlang? What is an example of these generic queues (or if it's only an ideal, what are its characteristics)?

codewright 14y ago
Just don't use it for big, long-lived work queues and you'll be fine. If the queue gets badly backed up, you're probably fucked. Larger, longer-lived work queues are really more of a Hadoop thing, not an in-memory queue thing.
- philsnow 14y ago
  > If the queue gets badly backed up, you're probably fucked. Isn't that true of any queue ?
  - codewright 14y ago
    Not really, no. Depends on what how narrow you are about the definition of "queue".
- klibertp 14y ago
  I got curious and googled a bit, here's what I found: http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-messaging-with-good-query-features http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-fo... Where the first answer states that: "RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general." (It's contrasted with Kafka, which is "designed for holding and distributing large volumes of messages") Still, I see no reason why you say that it's Erlang that causes this?
  - codewright 14y ago
    People often use Erlang primarily for the memory model. Pure in-memory didn't work for our use-case. You can implement a queue that works better for batch work in Erlang, it's just that it'd be closer to a data store.

klibertp 14y ago

I only said it is being used, not how good the products are... And CouchDB is a perfect example - from what I saw they use Erlang for what it's good at and use other tools where it's not appropriate - that's exactly how Erlang should be used[1]. [1] Or at least Joe Armstrong says so in his book, "Programming Erlang".

mietek 14y ago

> its known Can you point to any references?