Yes, we've had dynamic snitch on by default in all the 0.7 releases so
it's pretty well tested by this point.
On Wed, Apr 13, 2011 at 1:17 PM, Erik Onnen wrote:
> So we're not currently using a dynamic snitch, only the SimpleSnitch
> is at play (lots of history as to why, I won't go into it). If
So we're not currently using a dynamic snitch, only the SimpleSnitch
is at play (lots of history as to why, I won't go into it). If this
would solve our problems I'm fine changing it.
Understood re: client contract. I guess in this case my issue is that
the server we're connected to never tries mo
First, our contract with the client says "we'll give you the answer or
a timeout after rpc_timeout." Once we start trying to cheat on that
the client has no guarantee anymore when it should expect a response
by. So that feels iffy to me.
Second, retrying to a different node isn't expected to give
Sorry for the complex setup, took a while to identify the behavior and
I'm still not sure I'm reading the code correctly.
Scenario:
Six node ring w/ SimpleSnitch and RF3. For the sake of discussion
assume the token space looks like:
node-0 1-10
node-1 11-20
node-2 21-30
node-3 31-40
node-4 41-50
