Thanks for the comments. response inline and marked in blue, for easier
reading
On Tue, May 31, 2011 at 2:27 AM, Sylvain Lebresne wrote:
>
> Making the FIFO assumption stand in face of node failure is possible,
> but it's a complicated problem by itself. You basically have to make
> sure that whe
One more thing, if you keep one sub-count for each coordinator,
that won't be fun in a 400 nodes cluster. Or, to put this in another
way, you incur on the client the burden of making sure that for
each counter it will use a reasonably small set of coordinator ever.
Which can actually be a major hea
> we claim that, because of the FIFO assumption, here node 2 has seen
> all messages from coord 10 with a serial <=9, , and node 3 has seen
> all messages with serial <=14, so that node 2's history is a prefix of
> that of node 3. i.e. what we read out immediately from node 2
> represents a value
currently to prevent read failure in case of a single replica failure,
I need to specify CL > ONE when updating a counter, and when such an add
happens,
the wait is longer than a regular insert:
coordinator ---> leader ---> leader does sstable tally up > leader waits
for at least one replica t
