Fork me on GitHub
#clojure-uk
<
2016-08-16
>
jonpither11:08:19

happy lunch time one and all

mccraigmccraig11:08:27

so this morning zookeeper died of dysentery or something and totally shat all over its snapshots 😢

jonpither11:08:36

kill zookeeper with fire

jonpither11:08:04

unpleasant memories

mccraigmccraig11:08:09

first time it's ever un-recoverably borked for me

mccraigmccraig11:08:48

it looks like the ubuntu 14 current version has several critical bugs in it which are fixed in the following point releases

mccraigmccraig11:08:58

though the number of "critical" bugs in their release notes really doesn't inspire confidence

dominicm11:08:49

@mccraigmccraig: Do you use zookeeper directly?

mccraigmccraig11:08:49

@dominicm: indirectly - mesos, kafka and onyx all use it

dominicm12:08:19

That looks like you might have just opened up the rabbit hole I've been looking for ...

kevin4212:08:29

looks interesting, I’ve spotted a mini typo We introduce a single, general mechansim

otfrom12:08:17

kevin_e: maybe it isn't a typo and it is their neologism o_O

otfrom12:08:36

I like that this looks like it will apply to an awful lot of clojure style data structures too

dominicm12:08:14

I have a question that may relate to CRDTs: - User updates username to A - User very quickly updates username to B Due to distribution, B hits the database first. How do I prevent A from becoming the username?

mccraigmccraig12:08:05

@dominicm: in that case you could supply ordering information from the user's client to allow the server to discriminate with something like update users set username=X where id=ID and timestamp<Y

mccraigmccraig12:08:21

if there are two or more clients making concurrent changes with no obvious priority then you may want CRDTs

glenjamin12:08:25

update user set name=A where name=old is possibly the most general approach

glenjamin12:08:44

then if you do the same update twice, all is good

dominicm12:08:50

I think I see. I thought it might be. That was the best idea I had too. Could that break if a user tried A->A->B->A, and ended up with A->A->A->B ?

glenjamin12:08:56

yeah, the most robust is probably using the revision number, what to do when you actually do hit conflicts in interesting

dominicm12:08:57

Something else I'm trying to figure out is how to make idempotent writes. Onyx can retry a message if it's not sure it succeeded. Datomic is pretty easy if you create a custom transactor function which looks for transactions with a particular message-id. Something more traditional like postgres confuses me a little still though.

dominicm12:08:25

In general, datomic is great for distributed systems, because even if a write happens during a process, your reads are consistent.

dominicm12:08:12

Distributed systems just seem hard for updating state. Better to just store a history of messages and reprocess them on-demand.

otfrom12:08:03

dominicm: any ACID database should be consistent during reads (tho many are not configured that way)

dominicm12:08:23

Maybe I meant persistent. Especially for multiple reads.

dominicm12:08:48

If something doesn't process for 10s, I still want it to operate with the way the world was 10s ago, I think?

mccraigmccraig12:08:41

@dominicm: your history of messages is also state - all participants have to agree on the history, otherwise their notions of eventual state may be different

glenjamin12:08:52

most databases throw away context, the more you can keep, the more options you have to reconcile conflicts

dominicm12:08:34

😭 that's it. Distributed systems are dead to me. 🙂

dominicm12:08:00

Write last wins. Overwriting state like an atom. With no history.

dominicm12:08:30

In seriousness, is there a way I can learn to handle all of this stuff? Resources you guys could recommend?

glenjamin12:08:02

I reckon it’s entirely contextual, depending on what you’re building you may or may not need any of this

glenjamin12:08:38

for single-user-writing, configuring a majority quorum for writes should be plenty

glenjamin12:08:54

and multiple-users editing the same resource is a people problem 😄

dominicm13:08:40

One of my interests is replayable events, as in, you can rebuild your database from scratch from the list of events. But that means you must be truly consistent, you can't have out of order changes screwing with things.

dominicm13:08:37

So I guess that's my context really 😛

minimal13:08:45

@dominicm: Martin Kleppmann’s blog is a good resource and his book is really good https://martin.kleppmann.com/

dominicm13:08:38

@minimal: Ooh, thankyou!

minimal13:08:29

oh he is a co-author in the json crdt paper!

otfrom13:08:35

dominicm: generally finding books with animals on the cover that talk about computery things is a good start

otfrom13:08:00

there are a few other books out there from other publishers too (like Henry Garner's book)