cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Stucky <daniel.stu...@empolis.com>
Subject AW: Strange behavior of timestamp column
Date Mon, 05 Oct 2015 14:08:15 GMT
Please forget about this email,

there was a long forgotten client running somwhere in our data center that caused this problem.

Von: Daniel Stucky [mailto:daniel.stucky@empolis.com]
Gesendet: Montag, 5. Oktober 2015 09:02
An: user@cassandra.apache.org
Betreff: Strange behavior of timestamp column

Hi all,

we have a very simple cassandra table that contains just a single row. We have a 3-machine
cluster using Cassandra 2.1.8, cqlsh 5.0.1.

I do the following:

CREATE TABLE IF NOT EXISTS  scheduler_config (name text, suspended boolean, modified_ts timestamp,
last_scheduled_start_ts timestamp, last_triggered_start_ts timestamp, PRIMARY KEY((name)));
INSERT INTO  scheduler_config (name, last_scheduled_start_ts) VALUES('scheduler', '2015-01-01T00:00:00.000Z');

Now I do some select * on the table and always receive the same value for  last_scheduled_start_ts
that was inserted ('2015-01-01T00:00:00.000Z').
After 30-60 seconds the select * statement suddenly returns the current timestamp (e.g. '2015-10-05T09:00:00.000Z'
)instead of the inserted value.
Future select * requests also return this value ('2015-10-05T09:00:00.000Z'), so the timestamp
does change once but not with every request.


-          If I insert the initial value again, the same happens.

-          If I insert another value (in the past), the same happens.

-          Droping and recreating the table does not change anything

-          Repairing the table also has no effect


On the other hand

-          If I insert a value in the future (e.g. 2016) the inserted value is always returned.

-          If I set the second timestamp column, the inserted value for that column is always
 returned.

-          If I add a second row, the inserted value for both rows are always returned.

This behavior is really strange and seems to come from Cassandra itself (no active client
besides cqlsh).

As far as we can tell this behavior started to occur on September 30th 18:00:00 +0200 (not
sure i fit was so from the beginning, at least we did not notice this effect).
Before this time was a cassandra restart, as we increased server side timeouts.


Anybody any idea what is causing this problem ?

Thanks,
Daniel


Mime
View raw message