You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by William Katsak <wk...@cs.rutgers.edu> on 2012/10/24 21:57:54 UTC
Write Timestamps
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
RE: Write Timestamps
Posted by Jeremiah Jordan <JE...@morningstar.com>.
Sorry, should have said, "If you do not provide one, the CQL layer on the server adds the timestamp", unlike thrift where the timestamp is always client side.
Bill,
Glad 1.1.6 fixed your issue.
-Jeremiah
________________________________________
From: Eric Evans [eevans@acunu.com]
Sent: Thursday, October 25, 2012 4:09 PM
To: dev@cassandra.apache.org
Subject: Re: Write Timestamps
On Wed, Oct 24, 2012 at 9:13 PM, Jeremiah Jordan
<JE...@morningstar.com> wrote:
> How are you doing the write? CQL or Thrift? In thrift, the client specifies the timestamp, and you should always be seeing that as the timestamp. In CQL, the CQL layer on the server adds the timestamp.
For the record, you can supply a timestamp with CQL, same as you can
with Thrift. For example:
INSERT INTO somedb.sometable (id, given, surname) VALUES ('pgriffith',
'Peter', 'Griffith') USING TIMESTAMP 42;
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: Write Timestamps
Posted by Eric Evans <ee...@acunu.com>.
On Wed, Oct 24, 2012 at 9:13 PM, Jeremiah Jordan
<JE...@morningstar.com> wrote:
> How are you doing the write? CQL or Thrift? In thrift, the client specifies the timestamp, and you should always be seeing that as the timestamp. In CQL, the CQL layer on the server adds the timestamp.
For the record, you can supply a timestamp with CQL, same as you can
with Thrift. For example:
INSERT INTO somedb.sometable (id, given, surname) VALUES ('pgriffith',
'Peter', 'Griffith') USING TIMESTAMP 42;
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: Write Timestamps
Posted by William Katsak <wk...@cs.rutgers.edu>.
I was using Thrift...I discovered it while debugging a replica placement
scheme. I originally thought that my code was at fault, but then tried
it with the regular NetworkTopologyStrategy and saw the same thing.
However, I have now tried with 1.1.6 and everything seems to work fine
now. There must have been some bug that managed to make into the 1.1.5
release.
Thanks,
Bill
On 10/24/2012 10:13 PM, Jeremiah Jordan wrote:
> How are you doing the write? CQL or Thrift? In thrift, the client specifies the timestamp, and you should always be seeing that as the timestamp. In CQL, the CQL layer on the server adds the timestamp. I am less familiar with the CQL code, maybe something screwy is going on there. 1.1.6 is out, do you see the same behavior there?
>
> -Jeremiah
>
> On Oct 24, 2012, at 3:57 PM, William Katsak<wk...@cs.rutgers.edu> wrote:
>
>> 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<wk...@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
>>>
Re: Write Timestamps
Posted by Jeremiah Jordan <JE...@morningstar.com>.
How are you doing the write? CQL or Thrift? In thrift, the client specifies the timestamp, and you should always be seeing that as the timestamp. In CQL, the CQL layer on the server adds the timestamp. I am less familiar with the CQL code, maybe something screwy is going on there. 1.1.6 is out, do you see the same behavior there?
-Jeremiah
On Oct 24, 2012, at 3:57 PM, William Katsak <wk...@cs.rutgers.edu> wrote:
> 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<wk...@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
>>
>>
Re: Write Timestamps
Posted by William Katsak <wk...@cs.rutgers.edu>.
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<wk...@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
>
>
Re: Write Timestamps
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <wk...@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
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com