Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



I'm the author here of that blogpost.

The blog post was published on Feb 19th. First edit is from Feb 20th and second one from March 10th.

Aphyr's blog post is from June 6th 2014, so clearly we made the edits way before aphyr's blogpost came out.


> 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.

https://www.rabbitmq.com/distributed.html

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".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: