Show HN: Amqphosting, Managed RabbitMQ service
amqphosting.com
Show HN: Amqphosting, Managed RabbitMQ service
1–10 of 17 posts
Re: Show HN: Amqphosting, Managed RabbitMQ service
#2Looks nice, is it a single side project that you are launching? What are your experience with rabbitmq vs. SQS or something like it? :)
Re: Show HN: Amqphosting, Managed RabbitMQ service
#3Great idea. Nice to see a managed service for this.
When we used to use RabbitMQ we were never able to restart a fully loaded instance it always just seemed to hang.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#4My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this:
> With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition.
Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all. So that kind of rules out high availability, practically speaking. Shovel and federation are poor options.
As someone who is actively looking for highly available AMQP without message loss, I have to say that I'm not going to pay someone else for a poor solution to the problem. A managed service has to solve the hard problems to be compelling. I can run my own single instance and hope it doesn't go down at a bad time, which is all you're offering.
I know this is all very negative, and I regret that, but I'm part of your target market and you need to know what your offering looks like from my perspective. A managed service can't sidestep the difficult problems of operating their core technology.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#5Why not support TLS/amqps at all pricing levels? That's a huge turn off for me especially since you only have it at your highest pricing level. I'd also make that clear on your comparison page as it seems like you support amqps at the $55 level but do not on your pricing page. Good luck! (seriously, no sarcasm)
Re: Show HN: Amqphosting, Managed RabbitMQ service
#6My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this: > With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition. Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all.…
Totally agreed. A single Rabbit node is brain-dead easy to run - the hardest part is getting the right Erlang packages installed. HA Rabbit is a problem I'd be willing to pay someone else to solve for me.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#7My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this: > With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition. Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all.…
Indeed. In my opinion RabbitMQ is essentially useless in clustered mode.
When Rabbit recovers from a network partition and has to decide between multiple potential master versions of a queue, it picks the largest one to become the new master, and discards the others. It's rather mind-boggling that it can't merge them instead; after all, if your application is capable of handling duplicate deliveries, then merging (which would potentially result in previously ACKed messages becoming visible again) would be a perfectly acceptable solution.
The only way to make it non-lossy is to turn off HA recovery and manually handle network partitions, but it turns out that's not practically feasible, because there are no tools to work with Rabbit queues at a low level; the only way to recover is to discard one or more nodes.
We've also found Rabbit's clustering to be very flaky in general, beside the lack of partition tolerance. We recently had a Rabbit crash where one Rabbit node (not the machine itself) went down, and things got really stuck; the only way to recover was to stop all the nodes, then start them again. After we did that, all the queues were empty. We've also had instances where suddenly bindings go missing, or the bindings are there but attempting to declare them from a client fails with an "bindings already exist" error. And many other weird errors.
The last year or so, after having to endure all of these issues, we've decided to ditch clustering altogether and run a single node. That's risky, but ironically it's a lot more stable than our previous three-node cluster.
In my opinion, Pivotal really needs to redesign RabbitMQ's clustering.
Has anyone successfully moved off Rabbit? ActiveMQ, NSQ? Disque [1] looked promising, but seems dead (last commit was 18 months ago) at this point.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#8My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this: > With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition. Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all.…
Indeed. In my opinion RabbitMQ is essentially useless in clustered mode. When Rabbit recovers from a network partition and has to decide between multiple potential master versions of a queue, it picks the largest one to become the new master, and discards the others. It's rather mind-boggling that it can't merge them instead; after all, if your application is capable of handling duplicate deliveries, then merging (wh…
Antirez said he plans on merging disque into a Redis module, now that such a thing exists. I'm pretty excited, and would love to migrate off of RabbitMQ to Disque or whatever the module version is named, as we're already successfully running redis instances.
As for merging queues after partition recovery, the RabbitMQ devs have been talking about implementing that for years. I understand it's a hard problem, or it would already be part of RabbitMQ, since it's the most obvious and desirable solution for applications that can handle duplicates.
We're doing the same thing wrt avoiding clustering and accepting the brief downtime when the single RabbitMQ instance fails.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#9My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this: > With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition. Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all.…
I'm totally with you. I think the problem is AMQP itself. It just doesn't lend itself well to fully managed reliable message passing across network partitions because it was engineered (some say overengineered) to be "zero overhead" and have "delivery guarantees". If you need message passing across network partitions you really need to ask yourself if RabbitMQ is the right tool for the job. As services like Pubnub get cheaper and gain more acceptance from developers I think they will eliminate many of the things RabbitMQ is currently being used for. If you need message passing features that aren't either in RabbitMQ, Redis, or hosted services like Pubnub, then you're probably doing something sophisticated and probably want to build your infrastructure from the ground up.
Re: Show HN: Amqphosting, Managed RabbitMQ service
#10My first question when I saw this was "How to you handle network partitions?", since RabbitMQ's partition handling is, uh, suboptimal. I read bullet points until I found this: > With our RabbitMQ servers, you wont have to deal with message loss in the event of a network partition. Reading on, I found that your answer to partition tolerance is to avoid the possibility of partitions by not supporting clustering at all.…
Indeed. In my opinion RabbitMQ is essentially useless in clustered mode. When Rabbit recovers from a network partition and has to decide between multiple potential master versions of a queue, it picks the largest one to become the new master, and discards the others. It's rather mind-boggling that it can't merge them instead; after all, if your application is capable of handling duplicate deliveries, then merging (wh…
We run our RabbitMQ cluster with pause_minority as the partition handling strategy. This should eliminate most message loss on partition, no?