On Feb 25, 2012, at 8:46 PM, Armon Dadgar wrote:
> On Feb 25, 2012, at 5:38 PM, Reid Draper wrote:
>
>> On Feb 25, 2012, at 8:29 PM, Armon Dadgar wrote:
>>
>>> On Feb 25, 2012, at 5:24 PM, Reid Draper wrote:
>>>
>>> I'm not convinced that a CAS operation is inevitably subject to data
On Feb 25, 2012, at 5:38 PM, Reid Draper wrote:
> On Feb 25, 2012, at 8:29 PM, Armon Dadgar wrote:
>
>> On Feb 25, 2012, at 5:24 PM, Reid Draper wrote:
>>
>> I'm not convinced that a CAS operation is inevitably subject to data
>> races.
>> There are proven techniques for avoidin
On Feb 25, 2012, at 8:29 PM, Armon Dadgar wrote:
> On Feb 25, 2012, at 5:24 PM, Reid Draper wrote:
>
> I'm not convinced that a CAS operation is inevitably subject to data
> races.
> There are proven techniques for avoiding races at the cost of latency,
> which is acceptable
On Feb 25, 2012, at 5:24 PM, Reid Draper wrote:
I'm not convinced that a CAS operation is inevitably subject to data races.
There are proven techniques for avoiding races at the cost of latency,
which is acceptable in certain situations.
>>> Correct, but as far as I know, there
On Feb 25, 2012, at 8:18 PM, Armon Dadgar wrote:
> On Feb 24, 2012, at 7:46 PM, Reid Draper wrote:
>> The problem is that amongst all replicas for a particular key,
>> operations are not serializable. Put another way, if there
>> are concurrent writes to three replicas,
>> there is no way to figu
On Feb 24, 2012, at 7:46 PM, Reid Draper wrote:
> The problem is that amongst all replicas for a particular key,
> operations are not serializable. Put another way, if there
> are concurrent writes to three replicas,
> there is no way to figure out a total ordering for the actions.
>
> It's also i
As a follow-up, the node that was leaving is now stopped. The logging looks
kind of normal to me, but I notice that all handoffs went only to a single
other node. I have dumped the logging here:
http://pastebin.com/u6HYNjSZ
My cluster has nodes 1-6, node6 was already converted to 1.1 with Level
