That post talks about how to build a distributed semaphore using RabbitMQ in the "clustered" configuration option.
Aphyr's post is good but RabbitMQ make it pretty clear that this setup is not resilient to network partitions. They even mention it at the end of the blog post. That is also clear in the documentation.
The big general question is how likely are you to encounter network partitions?
Aphyr believes they are very dangerous and likely to happen to you at some point and should be taken more seriously by the programming world.
I tend to take a more of "it depends" on your environment. Recently with VM and cloud deployment network partitions are quite likely. So they should be at the top of your "things to worry about" list. But, I haven't seen it happen on a local LAN. During testing I have induced it by hand (but pulling the network cable out from a switch), but I just haven't seen it happen otherwise. I probably got lucky. Now I have seen other things come like memory corruption, memory leaks in software, and so on. So many other things that worry me more than network partition on a LAN.
All that said, it is great to see these experiments run. Please read and study all the other "Call me maybe" series. They are just very good. It turns out most products with a "distributed" component will fall over in the face of a partition. And keep in mind that it is best to have Aphyr discover these issues than your customers ;-)
I think this is a misunderstanding in terminology. "Network partition" in this context does not necessarily mean your LAN cable is broken, it means that you have a cluster of servers that expect to communicate, and some of them cannot communicate between each other.
That could be because of a faulty network, but it could also be due to hardware failures, misconfiguration, slowness of servers (hard to tell from not reachable), and a whole host of other causes. If you have more than just a couple of servers, this will happen sooner or later.
If you only have a couple of servers, IMHO don't bother with a truly distributed system, use a database with failover to a replication slave (lazy or eager, depending on what consistency you need) and be done with it.
If I'm reading the dates right, they admit its lack of resilience to partitions after the Aphyr blog post came out. That's a completely different thing than proactively raising this issue.
It's also not clear what if any usefulness a lock service has, beyond as a demonstration, if it can't survive partitions.
Network partitions are rare on small scale networks over short durations. But as the saying goes, if you run a billion trials, the one-in-a-million event happens a thousand times. The larger a network grows, the more likely you'll eventually experience the joy of a partition.
> they admit its lack of resilience to partitions after the Aphyr blog post came out. That's a completely different thing than proactively raising this issue.
In that blog post. This doc page was there long before.
Network partition tolerance is a general configuration trade-off not related just to that particular trick of distributed semaphores. Presumably someone who set up a clustered configuration already decided on the likely-hood of experiencing a network partition and read the docs.
Now there is a another issue explored and that is tolerance to network failures in general between clients and even a single server. That is (the way I understand it) not related to clustered or un-clustered configuration. It relates to the stability of network connections between clients and server(s).
I don't know if you read the blog post, but it demonstrates that the partition tolerant mode from the page you just linked is not actually, and that RabbitMQ, even in that mode, can't be used as a lock service.
I didn't see the part of the post about connections between clients and servers, but I was reading on mobile, so maybe I just missed it.
> but it demonstrates that the partition tolerant mode from the page you just linked is not actually
I was talking about the part about picking a response to a partition detection event. In this case "ignore" (see "Recommendations" section), instead of "auto-heal" or "minority-pause".
I've seen it happen, not what I'd call often but not so rare that you're astonished by it. NICs fail, switch ports or entire switches fail, stuff like that happens from time to time.
http://www.rabbitmq.com/blog/2014/02/19/distributed-semaphor...
That post talks about how to build a distributed semaphore using RabbitMQ in the "clustered" configuration option.
Aphyr's post is good but RabbitMQ make it pretty clear that this setup is not resilient to network partitions. They even mention it at the end of the blog post. That is also clear in the documentation.
https://www.rabbitmq.com/distributed.html
The big general question is how likely are you to encounter network partitions?
Aphyr believes they are very dangerous and likely to happen to you at some point and should be taken more seriously by the programming world.
I tend to take a more of "it depends" on your environment. Recently with VM and cloud deployment network partitions are quite likely. So they should be at the top of your "things to worry about" list. But, I haven't seen it happen on a local LAN. During testing I have induced it by hand (but pulling the network cable out from a switch), but I just haven't seen it happen otherwise. I probably got lucky. Now I have seen other things come like memory corruption, memory leaks in software, and so on. So many other things that worry me more than network partition on a LAN.
All that said, it is great to see these experiments run. Please read and study all the other "Call me maybe" series. They are just very good. It turns out most products with a "distributed" component will fall over in the face of a partition. And keep in mind that it is best to have Aphyr discover these issues than your customers ;-)