CL.ONE represents the fastest you can sustain. CL.ZERO represents writing to memory on the coordinator, regardless of what the nodes can sustain for durable writes. That is a bad situation, regardless of your durability goals. So, there is no good reason.
What you are describing is a non-existent CL in which the writes are dispatched to the replicas and success immediately returned to the client. Wouldn't be hard to add. On Mon, Jul 12, 2010 at 10:51 AM, B. Todd Burruss <[email protected]> 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? > > thx > > 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<[email protected]> >> 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? >>> >>> Thanks. >>> >>> Shen >>> >>> >
