Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reply to Aphyr attack on Redis Sentinel

antirez.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Reply to Aphyr attack on Redis Sentinel

#21

Post by andypiper »

undoware wrote: post #20
antirez wrote: post #13

Earlier quoted context omitted.

Hello, 1) I no longer work for VMware, but Pivotal. Redis is open source and copyright is of the original guys that wrote the code: I, Pieter Noordhuis, other contributors. 2) I posted the link to the original article in the first very lines of my reply. Actually thanks to my reply the exposure the Aphyr research had about Redis is the greatest, compared to the other data stores mentioned. I publicly said thank you t…

Sorry, to clarify -- I was suggesting that it was possible that VMWare (a sponsor of Redis, correct?) leaned on someone. I didn't mean to besmirch you or redis, antirez, and I enjoyed your response. It wouldn't be the first time a reputable news site was forced to bury a story by a litigious company. Sponsoring FOSS does not make any organization beyond doubt. Especially if they, say, have a history of suing anyone w…

As Antirez says, VMware were formerly a sponsor of Redis, and he now works for Pivotal (as do I), who are the current sponsor of the project. Either way, I'm highly skeptical that anyone at either company did such a thing.

Re: Reply to Aphyr attack on Redis Sentinel

#22

Post by jacquesm »

tptacek wrote: post #12
undoware wrote: post #10

I'm frustrated that when the HN editors deduped the original story, they apparently deleted ALL the instances, leaving only this one. I wanted to read the discussion on the subject of Aphyr's research, not Antirez' response. It looks bad, HN. We all know that VMWare is litigious as (try looking up benchmarks sometime.) But to (presumably) cave so quickly and effortlessly suggests... well, I'm not sure. The other poss…

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.

Re: Reply to Aphyr attack on Redis Sentinel

#24

Post by undoware »

andypiper wrote: post #21
undoware wrote: post #20

Earlier quoted context omitted.

Sorry, to clarify -- I was suggesting that it was possible that VMWare (a sponsor of Redis, correct?) leaned on someone. I didn't mean to besmirch you or redis, antirez, and I enjoyed your response. It wouldn't be the first time a reputable news site was forced to bury a story by a litigious company. Sponsoring FOSS does not make any organization beyond doubt. Especially if they, say, have a history of suing anyone w…

As Antirez says, VMware were formerly a sponsor of Redis, and he now works for Pivotal (as do I), who are the current sponsor of the project. Either way, I'm highly skeptical that anyone at either company did such a thing.

I have a background in ethics and law so I've seen too much to make apologies for being suspicious. :) In fact, this sort of suspicion is a good reason NOT to establish a track record of litigating away freedom of speech (as VMWare notoriously threatens to do if someone publishes their benchmarks). But again: nothing to do with Redis, if (as you say) VMWare is no longer a sponsor.

Re: Reply to Aphyr attack on Redis Sentinel

#25

Post by fdr »

aphyr wrote: post #7
pygy_ wrote: post #4

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…

Database constraints usually catch these problems in event of re-submission, especially if the client can assign primary keys (e.g., a UUIDv4) a-priori, but this also tends to be true in simpler cases, too.

All in all, I am not sure if anyone should find this surprising: if anyone has ever had a network stall when clicking the 'confirm' button at a web-based store, they are familiar with the uncertainty as to whether the order has been submitted or not (resolved typically by browsing the history or waiting for an email, or no).

I would guess modern e-commerce vendors would send you a UUID or moral equivalent to de-dup cart resubmissions these days...but if not, it'd be interesting to know why not.

Re: Reply to Aphyr attack on Redis Sentinel

#26

Post by aphyr »

fdr wrote: post #25
aphyr wrote: post #7

Earlier quoted context omitted.

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…

Database constraints usually catch these problems in event of re-submission, especially if the client can assign primary keys (e.g., a UUIDv4) a-priori, but this also tends to be true in simpler cases, too. All in all, I am not sure if anyone should find this surprising: if anyone has ever had a network stall when clicking the 'confirm' button at a web-based store, they are familiar with the uncertainty as to whether…

Correct; if your writes are idempotent, retrying is safe. I cover this in the post as well. My above comment shows that it's possible to recover consistency even for writes which are not idempotent--though depending on the semantics of your retries, there may be some locking required.

Re: Reply to Aphyr attack on Redis Sentinel

#27

Post by hendzen »

antirez wrote: post #15
aphyr wrote: post #14

Earlier quoted context omitted.

https://www.hnsearch.com/search#request/all&q=aphyr.com HN stories on my original posts are still there, as far as I can tell. They just never hit frontpage.

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.

Re: Reply to Aphyr attack on Redis Sentinel

#28

Post by jamwt »

Glyptodon wrote: post #8

Redis is one of those things I both love and love to hate. I've had good results using Redis as a lock server, but I live in (perhaps misplaced) fear of a client hanging or crashing leaving a lock stranded. Not that this is really Redis's problem.

I recommend dreadlock:

https://github.com/jamwt/dreadlock

It will release the lock when the client dies (disclaimer: I wrote it).

Or you can go whole hog and use zookeeper + ephemeral nodes. More robust but quite a bit more complex.

Re: Reply to Aphyr attack on Redis Sentinel

#29

Post by danso »

brown9-2 wrote: post #23

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

Really? I hadn't seen the original posts before clicking on the this one and I assumed this was some kind of security breach...I hadn't heard of Aphyr before but just assumed it was some kind of netsec (white or black hat) group. I actually skimmed the OP's first paragraphs several times because I didn't understand what was going on.

That said, I agree that DB reliability should be taken with the same rigor as net security...but I was kind of under the impression that it already was, in that DBs are pretty serious business. Also, "attack" has the connotation of, well, an "attack"...here, some of the failures happen in regular business operations, which is a problem different from when the system is under "attack".

But at least the OP took the criticism graciously. When I read what the case actually was, I then worried that the OP was having a bunker mentality.

Re: Reply to Aphyr attack on Redis Sentinel

#30

Post by rmaccloy »

Glyptodon wrote: post #11
antirez wrote: post #9

Earlier quoted context omitted.

Hello, you can easily mount a lock that auto-releases itself after some timeout using the new (2.6.13) extended SET command (see http://redis.io/commands/set ) or simply a Lua script.

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)

Post reply on HN