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 <john.sanda@gmail.com> 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 CassandraDaemon.java (line 132) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.RuntimeException: Cannot create CompressionParameters for stored parameters
        at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:99)
        at org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:63)
        at org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.complete(CompressedSegmentedFile.java:51)
        at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:404)
        at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:198)
        at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
        at org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:238)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
        at java.util.concurrent.FutureTask.run(FutureTask.java:177)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
        at java.lang.Thread.run(Thread.java:780)
Caused by: org.apache.cassandra.exceptions.ConfigurationException: SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError org.xerial.snappy.Snappy (initialization failure)
        at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:179)
        at org.apache.cassandra.io.compress.CompressionParameters.<init>(CompressionParameters.java:71)
        at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:95)
        ... 12 more
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:613)
        at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:156)
        ... 14 more
Caused by: java.lang.NoClassDefFoundError: org.xerial.snappy.Snappy (initialization failure)
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:176)
        at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
        ... 19 more
Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
        at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
        at org.xerial.snappy.Snappy.<clinit>(Snappy.java:44)
        at java.lang.J9VMInternals.initializeImpl(Native Method)
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:236)
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:150)
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:366)
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:409)

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.


Thanks

- John