On 04/12/2011 06:27 PM, Peter Schuller wrote:
>> So to increase pinny-ness I'll further reduce RR chance and set a
>> badness threshold. Thanks all.
>
> Just be aware that, assuming I am not missing something, while this
> will indeed give you better cache locality under normal circumstances
> -
> To now answer my own question, the critical points that are different
> from what I said earlier are: that CL.ONE does prefer *one* node (which
> one depending on snitch) and that RR uses digests (which are not
> mentioned on the wiki page [1]) instead of comparing raw requests.
I updated it to
Peter, thank you for the extremely detailed reply.
To now answer my own question, the critical points that are different
from what I said earlier are: that CL.ONE does prefer *one* node (which
one depending on snitch) and that RR uses digests (which are not
mentioned on the wiki page [1]) instead
Nice explanation.
Wanted to add the importance of been the first node in the ordered node list,
even for CL ONE, is that this is the node sent the data request and it has to
return before the CL is considered satisfied. e.g. CL One with RR running, read
sent to all 5 replicas, if 3 digest reque
Ok, I took this opportunity to look look a bit more on this part of
the code. My reading of StorageProxy.fetchRows() and related is as
follows, but please allow for others to say I'm wrong/missing
something (and sorry, this is more a stream of consciousness that is
probably more useful to me for le
My understanding for For CL.ONE. For the node that receives the request:
(A) If RR is enabled and this node contains the needed row --> return
immediately and do RR to remaining replicas in background.
(B) If RR is off and this node contains the needed row --> return the
needed data immediately.
