Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
Linux 2.6.27
-
Normal
Description
Tested on a vanilla single-node cassandra 1.0.9 installation.
When using super columns along with row caching via ConcurrentLinkedHashCacheProvider (default if no JNA available, or explicitly configured even if JNA available), there's what appears as transient data loss.
Given this script executed in cassandra-cli:
create keyspace Test;
use Test;create column family Users with column_type='Super' and key_validation_class='UTF8Type' and comparator='UTF8Type' and subcomparator='UTF8Type' and default_validation_class='UTF8Type' and rows_cached=75000 and row_cache_provider='ConcurrentLinkedHashCacheProvider';
set Users['mina']['attrs']['name'] = 'Mina';
get Users['mina'];set Users['mina']['attrs']['country'] = 'Canada';
get Users['mina'];set Users['mina']['attrs']['region'] = 'Quebec';
get Users['mina'];
The output from the 3 gets above is as follows:
=> (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
=> (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
=> (super_column=attrs,
(column=name, value=Mina, timestamp=1335377788441000))
Returned 1 results.
It's clear that the second and third set commands (country, region) are missing in the returned results.
If the row cache is explicitly invalidated (in a second terminal, via `nodetool -h localhost invalidaterowcache Test Users`), the missing data springs to life on next 'get':
[default@Test] get Users['mina'];
=> (super_column=attrs,
(column=country, value=Canada, timestamp=1335377839592000)
(column=name, value=Mina, timestamp=1335377788441000)
(column=region, value=Quebec, timestamp=1335377871353000))
Returned 1 results.
From cursory checks, this does not to appear to happen with regular columns, nor with JNA enabled + SerializingCacheProvider.