31–40 of 42 posts
Earlier quoted context omitted.
It is extremely unlikely that any pressure was put on the HN admins by VMWare or anyone else to get stories scrubbed. It's almost as unlikely that VMWare gives a shit about stories about Redis.
It's not unlikely they got a bunch of (unjust) flags.
Tangentially related: In the PostgreSQL evaluation[0], Aphyr noticed that, if a packet confirming a transaction is dropped, the client ends up in a deadlock. Does PostgreSQL keep a record of the past transactions, and their success or failure. If so, is it possible to query it? [0] http://aphyr.com/posts/282-call-me-maybe-postgres
Yes, you can recover from lost acknowledgements by asking for the transaction ID from postgres before committing--or by making up your own flake ID and writing it to a table. Given a queue with at-least-once delivery (which includes, say, durable storage on the client), you can check for the presence of that ID at a later time and re-apply the transaction to recover from network errors safely. The transaction ID does…
Thanks for the explanation.
It's very refreshing to see here that "attack" is not used in the way that one might expect from just the headline, meaning "a possibly unwarranted criticism that I didn't like or found unfair, or that I am taking personally".
My opinion of him and the Redis project increases further every time.
Earlier quoted context omitted.
Since the jobs we're locking can have somewhat inconsistent times we're actually using an implementation where the tasks can get a lock with a time limit and can extend their lock so long as they still have it, so they do potentially auto-release. Even given this, bad lock timing (not that likely) or a crash (more likely) could let inconsistency in. Shrugs Like I said, my problem is not really Redis's. If I can't tru…
We're about to open source a similar deal (redis-based "soft guarantee" mutexes) -- ours is written in Python and mostly used as a way to coordinate (very frequent) parallel task execution a la CountDownLatch, so 100% reliable exclusion in the face of failure isn't critical. I'd be interested to hear about your implementation if you can share (email is HN username at gmail.com)
Earlier quoted context omitted.
Aphyr, this is very lame, it's not common to see a work like what you did, and none of your stories hit the HN front page? I don't know what to think, but I hope that at least my post will help to show more people your awesome work.
I think Aphyr's series was a little too meaty for the general HN audience (of today). Talking about things like the FLP impossibility result, CAP theorem and specifying protocols with TLA+ may be a bit over the heads of many HN readers - clearly, people would rather read stories about the latest funding round, acquisition or frontend UI framework than a substantive article on distributed systems.
DRBD? http://drbd.org/
http://aphyr.com/posts/287-asynchronous-replication-with-fai...
DRBD? http://drbd.org/
Same limitations as any asynchronously replicated system; if both nodes diverge during a partition, you'll probably have to drop one's writes. http://aphyr.com/posts/287-asynchronous-replication-with-fai...