cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sanda <>
Subject Re: sstable_compression for system tables
Date Fri, 03 May 2013 16:35:32 GMT
I am still trying to sort this out. When I run with Oracle's JRE, it does
in fact look like compression is enabled for system tables.

cqlsh> DESCRIBE TABLE system.schema_columnfamilies ;

CREATE TABLE schema_columnfamilies (
  keyspace_name text,
  columnfamily_name text,
  bloom_filter_fp_chance double,
  caching text,
  column_aliases text,
  comment text,
  compaction_strategy_class text,
  compaction_strategy_options text,
  comparator text,
  compression_parameters text,
  default_read_consistency text,
  default_validator text,
  default_write_consistency text,
  gc_grace_seconds int,
  id int,
  key_alias text,
  key_aliases text,
  key_validator text,
  local_read_repair_chance double,
  max_compaction_threshold int,
  min_compaction_threshold int,
  populate_io_cache_on_flush boolean,
  read_repair_chance double,
  replicate_on_write boolean,
  subcomparator text,
  type text,
  value_alias text,
  PRIMARY KEY (keyspace_name, columnfamily_name)
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='ColumnFamily definitions' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=8640 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

Unfortunately the Cassandra instance that was running with IBM Java was on
a test virtual machine that has seen been deleted. Even if system tables
are getting created with compression enabled, I do not see how that would
happen with IBM Java where it fails to load the native snappy library.
CFMetadata.DEFAULT_COMPRESSOR should be null when snappy is not available.

On Fri, May 3, 2013 at 11:00 AM, Edward Capriolo <>wrote:

> I did not know the system tables were compressed. That would seem like an
> odd decision you would think that the system tables are small and would not
> benefit from compression much. Is it a static object static object that
> requires initialization even though it is not used?
> On Fri, May 3, 2013 at 10:19 AM, John Sanda <> wrote:
>> Is there a way to change the sstable_compression for system tables? I am
>> trying to deploy Cassandra 1.2.2 on a platform with IBM Java and 32 bit
>> arch where the snappy-java native library fails to load. The error I get
>> looks like,
>> ERROR [SSTableBatchOpen:1] 2013-05-02 14:42:42,485 (line 132)
Exception in thread Thread[SSTableBatchOpen:1,5,main]
>> java.lang.RuntimeException: Cannot create CompressionParameters for stored parameters
>>         at<init>(
>>         at
>>         at$Builder.complete(
>>         at
>>         at
>>         at
>>         at$
>>         at java.util.concurrent.Executors$
>>         at java.util.concurrent.FutureTask$Sync.innerRun(
>>         at
>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>         at java.util.concurrent.ThreadPoolExecutor$
>>         at
>> Caused by: org.apache.cassandra.exceptions.ConfigurationException: SnappyCompressor.create()
threw an error: java.lang.NoClassDefFoundError org.xerial.snappy.Snappy (initialization failure)
>>         at
>>         at<init>(
>>         at<init>(
>>         ... 12 more
>> Caused by: java.lang.reflect.InvocationTargetException
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>         at java.lang.reflect.Method.invoke(
>>         at
>>         ... 14 more
>> Caused by: java.lang.NoClassDefFoundError: org.xerial.snappy.Snappy (initialization
>>         at java.lang.J9VMInternals.initialize(
>>         at
>>         ... 19 more
>> Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
>>         at org.xerial.snappy.SnappyLoader.load(
>>         at org.xerial.snappy.Snappy.<clinit>(
>>         at java.lang.J9VMInternals.initializeImpl(Native Method)
>>         at java.lang.J9VMInternals.initialize(
>>         at org.apache.cassandra.service.CassandraDaemon.setup(
>>         at org.apache.cassandra.service.CassandraDaemon.activate(
>>         at org.apache.cassandra.service.CassandraDaemon.main(
>> I am not able to change sstable_compression for system tables from either
>> cassandra-cli or from cqlsh. I should point out that the DataStax docs do
>> state that system tables cannot be altered. I was wondering though if there
>> might be another way to do so.
>> Simply not using IBM Java is not an option for me. There is already an
>> issue[1] open with the snappy-java project that I think will address this
>> issue; however, that would involve packaging a new version of snappy-java
>> with Cassandra (when the fix is available). I would like to better
>> understand the impact of switching to a patched and/or upgraded version of
>> snappy-java before making that change.
>> [1]
>> Thanks
>> - John


- John

View raw message