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

I'm a newbie and a little confused. On one hand there are posts like this that claim exactly-once delivery and distributed locks are impossible. But on the other hand, if I look at the docs of a distributed database, say Apache Ignite, they will say that they have exactly-once delivery [1] and distributed locks [2]. So ... which is it?

[1] https://ignite.apache.org/docs/latest/key-value-api/continuo...

[2] https://ignite.apache.org/docs/latest/distributed-locks



This is exactly the kind of stuff I wrote this post about. The first (exactly once) is actually just at-least-once with deduplication based on a counter. To reliably process the events, however, you need to make your downstream idempotent as well. Think of it like your event processor might fail, so even if you only receive the message "once" if you can fail processing it you still have to think about retries. In my opinion it would be explicitly better for the event system to provide "at least once" and intentionally duplicate events on occasion to test your processors ability to handle duplicates.

The second (lock) is actually a lease fwict, and writing code in the locked body that assumes it will be truly mutually exclusive is pretty dangerous (see the linked post from Martin [1] for why).

[1] https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...


> In my opinion it would be explicitly better for the event system to provide "at least once" and intentionally duplicate events on occasion to test your processors ability to handle duplicates.

You're a madman, but I think you're right.

Thanks for the locking link.


Software vendors lie. Even open source ones. In some cases they get REALLY close to the truth, but aren't forthcoming with that last 1% case where their statement becomes a lie.

If you want to see a ton of lies, go and start reading through all the Jepsen posts tearing down those dubious claims.

http://jepsen.io/analyses




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

Search: