Here is what I am seeing on each replica node. This is after a write
with consistencylevel=ALL.
DEBUG [MutationStage:48] 2012-10-24 16:56:01,050
RowMutationVerbHandler.java (line 56) RowMutation(keyspace='normal',
key='746573746b65793337', modifications=[ColumnFamily(data
[636f6c:false:3@1351112161048000,])]) applied. Sending response to
770151@/172.16.18.112
DEBUG [MutationStage:59] 2012-10-24 16:56:02,889
RowMutationVerbHandler.java (line 56) RowMutation(keyspace='normal',
key='746573746b65793337', modifications=[ColumnFamily(data
[636f6c:false:3@1351112162785000,])]) applied. Sending response to
770152@/172.16.18.112
DEBUG [MutationStage:46] 2012-10-24 16:55:59,129
RowMutationVerbHandler.java (line 56) RowMutation(keyspace='normal',
key='746573746b65793337', modifications=[ColumnFamily(data
[636f6c:false:3@1351112159127000,])]) applied. Sending response to
770153@/172.16.18.112
Now, if I do a read of this data, I will always see a digest failure the
first time.
Thanks,
Bill
On 10/24/2012 04:09 PM, Jonathan Ellis wrote:
> Timestamps are part of the ColumnFamily objects and their Columns,
> contained in the RowMutation.
>
> On Wed, Oct 24, 2012 at 2:57 PM, William Katsak<wkatsak@cs.rutgers.edu> wrote:
>> Hello,
>>
>> I sent this message a few days ago, but it seems to have gotten lost (I
>> don't see it on the archive), so I am trying again.
>>
>> -----
>>
>> I am using Cassandra for some academic-type work that involves some hacking
>> of replica placement, etc. and I am observing a strange behavior (well,
>> strange to me).
>>
>> Using the stock 1.1.5 snapshot, when you do a write (even with
>> consistencylevel = ALL), it seems that all nodes will get the data with a
>> slightly different timestamp, and any read (even at ALL) with always have a
>> digest failure on the first read (and subsequent reads until read repair
>> catches up).
>>
>> It would make sense to me that timestamps should be distributed with the
>> RowMutation, not set on each node independently.
>>
>> Is this the intended behavior? Is there a design reason for this that I
>> should be aware of?
>>
>> Thanks,
>> Bill Katsak
>
>
|