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
>
>
>