On 6/16/2011 9:36 PM, Dan Hendry wrote:
"Help me out here. I'm trying to visualize a situation where the
clients can access all the C* nodes but the nodes can't access each
other. I don't see how that can happen on a regular ethernet subnet
in one data center. Well, I"m sure there is a case
"Help me out here. I'm trying to visualize a situation where the clients
can access all the C* nodes but the nodes can't access each other. I don't
see how that can happen on a regular ethernet subnet in one data center.
Well, I"m sure there is a case that you can point out. Ok, I will concede
On 6/16/2011 7:56 PM, Dan Hendry wrote:
How would your solution deal with complete network partitions? A node
being 'down' does not actually mean it is dead, just that it is
unreachable from whatever is making the decision to mark it 'down'.
Following from Ryan's example, consider nodes A, B,
UPDATE to my suggestion is below.
On 6/16/2011 5:50 PM, Ryan King wrote:
On Thu, Jun 16, 2011 at 2:12 PM, AJ wrote:
On 6/16/2011 2:37 PM, Ryan King wrote:
On Thu, Jun 16, 2011 at 1:05 PM, AJwrote:
The Cassandra consistency model is pretty elegant and this type of
approach breaks that
How would your solution deal with complete network partitions? A node being
'down' does not actually mean it is dead, just that it is unreachable from
whatever is making the decision to mark it 'down'.
Following from Ryan's example, consider nodes A, B, and C but within a
fully partitioned network
On Thu, Jun 16, 2011 at 2:12 PM, AJ wrote:
> On 6/16/2011 2:37 PM, Ryan King wrote:
>>
>> On Thu, Jun 16, 2011 at 1:05 PM, AJ wrote:
>
>>
The Cassandra consistency model is pretty elegant and this type of
approach breaks that elegance in many ways. It would also only really be
>>>
On 6/16/2011 2:37 PM, Ryan King wrote:
On Thu, Jun 16, 2011 at 1:05 PM, AJ wrote:
The Cassandra consistency model is pretty elegant and this type of
approach breaks that elegance in many ways. It would also only really be
useful when the value has a high probability of being updated between
On Thu, Jun 16, 2011 at 1:05 PM, AJ wrote:
> On 6/16/2011 10:58 AM, Dan Hendry wrote:
>>
>> I think this would add a lot of complexity behind the scenes and be
>> conceptually confusing, particularly for new users.
>
> I'm not so sure about this. Cass is already somewhat sophisticated and I
> don
On 6/16/2011 10:58 AM, Dan Hendry wrote:
I think this would add a lot of complexity behind the scenes and be
conceptually confusing, particularly for new users.
I'm not so sure about this. Cass is already somewhat sophisticated and
I don't see how this could trip-up anyone who can already gras
consistency level definition should be a definition of requirement from the
application perspective,
it should not be tied to some ephemeral state in the system (: a node being
deemed "available/up" or down is determined by
the gossip and changes every second )
what you want can be simply achieve
Original Message-
From: Ryan King [mailto:r...@twitter.com]
Sent: June-16-11 12:05
To: user@cassandra.apache.org
Subject: Re: Propose new ConsistencyLevel.ALL_AVAIL for reads
On Thu, Jun 16, 2011 at 8:18 AM, AJ wrote:
> Good morning all.
>
> Hypothetical Setup:
> 1 data c
On 6/16/2011 10:05 AM, Ryan King wrote:
I don't think this buys you anything that you can't get with quorum
reads and writes.
-ryan
QUORUM <= ALL_AVAIL <= ALL == RF
On Thu, Jun 16, 2011 at 8:18 AM, AJ wrote:
> Good morning all.
>
> Hypothetical Setup:
> 1 data center
> RF = 3
> Total nodes > 3
>
> Problem:
> Suppose I need maximum consistency for one critical operation; thus I
> specify CL = ALL for reads. However, this will fail if only 1 replica
> endpoint
Good morning all.
Hypothetical Setup:
1 data center
RF = 3
Total nodes > 3
Problem:
Suppose I need maximum consistency for one critical operation; thus I
specify CL = ALL for reads. However, this will fail if only 1 replica
endpoint is down. I don't see why this fail is necessary all of the
14 matches
Mail list logo
