The appearance of the old rows were caused by old timestamps set on
columns (which in turn caused by some ThreadLocals which were not
cleaned up). Since I fixed the timestamp, all rows returned corresponds
to their latest saved state in each and every case.
On 2012.02.20. 13:32, Hontvári József Levente wrote:
I noticed a strange phenomenon with Cassandra, and I would like to
know if this is something completely impossible, or not.
As you can see in the log extract below, as new versions of a row is
written out, the reads returns obsolete data after a while (they read
version 78 when 79 and even 80 is already written out). There is only
a single Cassandra node in the cluster, the client is on the same
local network, there are about 10 rows written and read per seconds. I
would think that in this test environment I should not see any
obsolete data at all. But actually I have thousands of log entries
after a few hours of test, which say that the row which was read does
not match the latest data which was written.
I checked in detail the history of another node, and it seems that
eventually I receive an up-to-date row, but it took once 10 and once
15 minutes in this specific case.
(FYI: I am just started to evaluate Cassandra, without any significant
experience.)
09:43:46Z Persisting version=77
GOOD 09:45:20Z Loading version=77
09:45:21Z Persisting version=78
GOOD 09:46:23Z Loading version=78
09:46:23Z Persisting version=79
WRONG! 09:47:12Z Loading version=78
09:47:12Z Persisting version=80
WRONG!! 09:49:20Z Loading version=78
09:49:20Z Persisting version=81
