Hi Douglas,
That seems to be a good candidate for an explanation. Thank you very
much for the explanation and link. I'll dig into it.
As promised, I looked into whether we in the second case I mentioned
also had "unrecognized message" in the logs, and we indeed had.
On Tue, Apr 18, 2017 at 2:
This sounds like an issue our Riak CS team ran into quite a while ago, which
involved “slow nodes” and coordination retry. Take a look at
https://github.com/basho/riak_kv/issues/1188 and see if it makes sense to you,
but it certainly sounds like what’s happening.
The basic flow of the issue com
Hi Magnus,
This cluster has been running in production for a few months. Key
generation is based on flake (https://github.com/boundary/flake); we
have never experienced a collision in the 3+ years we have been using
it heavily in production. However, I will look into that possibility
as well.
I j
On 18 April 2017 at 08:20, Daniel Abrahamsson wrote:
> I've run into a case where I got a sbiling error/response on the first
> ever write to a key. I would like to understand how this could happen.
> Normally when you get siblings, it is because you have written a value
> with an out-of-date vcl
I've run into a case where I got a sbiling error/response on the first
ever write to a key. I would like to understand how this could happen.
Normally when you get siblings, it is because you have written a value
with an out-of-date vclock. But since this is the first write, there
is no vclock. Cou
