fpj's comments

At this point, I don't have it clear that this is going to be accepted and adopted. If it is, then it isn't clear what the economic impact will be. Companies still need the job done to be competitive, and clearly no one will be happy with pay cuts. In a country in which the industry overall is struggling, it sounds like a risky move. At the personal level, I understand the benefits of having more personal and family time, though.

Is that supposed to be the King of Technology or the King of Techno Music?

Has worked fine for me in Spain all day.

A performance evaluation of Pravega.

>> Does the processes read or propose the value ?

It does both, it first proposes by writing a sequential znode and then reads the children (all proposals are written under some parent znode). This is certainly assuming some experience with ZK, and I wonder if that's the problem. It was not the goal to go into a discussion of the ZooKeeper API, but I'm happy to clarify if this is what is preventing you from getting the point.

>> Not suppose to ? How do you ensure that ?

It is not supposed to in the sense that if this is implemented right, then the proposed values for each client won't change. The recipe guarantees it because it assumes that each client writes just once.

>> Sorry, but I fail to see what recipe you speak about.

I'm referring to these three steps: creating a sequential znode under a known parent, reading the children, picking the value in the znode with smallest sequence number.

yeah, this is precisely what we do in Apache BookKeeper, and we map N to ack quorums and M to write quorums.

Thanks for your comments, and I'm sorry that you feel that the post does not match your expectation. If you write me directly, I'll be more than happy to clarify any question you may have. I'm not sure, for example, what is confusing you about the "zookeeper and consensus" section. I'm also not sure what kind of evidence you're after on published messages being lost.

Got it, yeah, quorum systems have higher tolerance to tail latency, there is no question about it. we do mention it briefly in the post, but we don't have numbers to show. I'm not aware of it being a major concern for kafka deployments, but I can say that for Apache BookKeeper, we ended up adding the notion of ack quorums to get around such latency spikes. I'll see if I can gather some more information about kafka that we can share at a later time. Thanks for raising this point.

I'm happy you enjoyed the post and thanks for the comment.

If I understand your comment correctly, it isn't the case that the ISR is fixed. The ISR has a minimum size, but it can change over time, so brokers can be removed from the ISR and they can rejoin later once they catch up.

I'm glad you enjoyed the post. The chain replication work indeed relies on a paxos-based master service for reconfiguration, but I believe that's the only similarity, the replication scheme is different otherwise.

Thanks for the comment, the vertical paxos reference is indeed relevant here.