My understanding is that the coordinator will acknowledge the writes faster then they can actually be written. Eventually it will run out of buffer space.
Using CL.ONE makes it harder for the clients to flood the cluster with more writes than it can perform. As usual add more nodes to add more write throughput.
On 13 Jul, 2010,at 05:51 AM, "B. Todd Burruss" <email@example.com> wrote:
why is there no good reason? if i would like to record informational
events, possibly for debugging or something, i don't care if they
actually get saved and i want the client's request to be as fast as
possibly. this sounds like a good reason.
are you saying that CL.ONE is equally performant? or possibly better by
your comment that ZERO can be a serious resource hog?
On 07/11/2010 11:09 AM, Benjamin Black wrote:
> And, to be clear, there is no good reason to use CL.ZERO and it can be
> a serious resource hog on the coordinator.
> On Sun, Jul 11, 2010 at 9:21 AM, ChingShen<firstname.lastname@example.org> wrote:
>> Hi all,
>> Does it mean that the coordinator node always return success to the client
>> at CL.ZERO? But if the coordinator node sends a request to a given node
>> B(RF=1), then B is down, what happened? The coordinator node will write the
>> hint locally?