Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 255ACF46D for ; Fri, 3 May 2013 18:07:42 +0000 (UTC) Received: (qmail 89139 invoked by uid 500); 3 May 2013 18:07:39 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 88997 invoked by uid 500); 3 May 2013 18:07:39 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 88986 invoked by uid 99); 3 May 2013 18:07:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2013 18:07:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of john.sanda@gmail.com designates 209.85.128.51 as permitted sender) Received: from [209.85.128.51] (HELO mail-qe0-f51.google.com) (209.85.128.51) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2013 18:07:29 +0000 Received: by mail-qe0-f51.google.com with SMTP id x7so1045681qeu.38 for ; Fri, 03 May 2013 11:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=+VTldMpsmhZ5rjg1R+pI7LNO8MyKBVxXufgdKxUSFKs=; b=TCCaX2PlM2+/5WMtgFAj0x7VcKEST2OEI7OwUMpHzFmtZH2JqYKdW42xrTnmE536dE LTpyj8/T9LaOrg7LAwe9040mbw/mG+5M4HeU39VCM+VHnP5xMOrxoXt3jiSyYCy+oVa6 9jX9ZBdDQCGOjHRPAhtcja2hLe9ywqdHzPP5mzu2HEht5ANaynYPNeVE7ekHoBS4Q12z H1a7NHfgjdetMYV/Ofokav8MwLMQhv7zx37BtWwp0VHY+i+YO9UptU2K6ikcPMRFGF36 cL+EczfpU+Rxmy0EuDwoIBNJzGgMd/O2i5UZpHjNpWa1JrC/jnnbgyq1kpH2Aj3ewaaa Pk1Q== MIME-Version: 1.0 X-Received: by 10.224.78.193 with SMTP id m1mr13802423qak.79.1367604428165; Fri, 03 May 2013 11:07:08 -0700 (PDT) Received: by 10.49.49.163 with HTTP; Fri, 3 May 2013 11:07:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 May 2013 14:07:08 -0400 Message-ID: Subject: Re: sstable_compression for system tables From: John Sanda To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf306f750c2256b204dbd438b7 X-Virus-Checked: Checked by ClamAV on apache.org --20cf306f750c2256b204dbd438b7 Content-Type: text/plain; charset=ISO-8859-1 The machine where this error occurred had both OpenJDK and IBM's Java installed. The only way I have been able to reproduce is by installing Cassandra with OpenJDK, shutting it down, the starting it back up with IBM Java. Snappy compression is enabled with OpenJDK so SSTables, including for system tables, are created with compression. Then when I start Cassandra back up with IBM Java, it cannot read those compressed files. This situation only happened as a result of switching JREs which is not too likely for a production deployment. When I install and deploy Cassandra using IBM Java from the get go, tables are created with compression disabled as expected. System tables though are in fact created with snappy compression if it is available. On Fri, May 3, 2013 at 12:35 PM, John Sanda wrote: > 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) > ) WITH > 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 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.(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.(CompressionParameters.java:71) >>> at org.apache.cassandra.io.compress.CompressionMetadata.(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.(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. >>> >>> [1] https://github.com/xerial/snappy-java/issues/34 >>> >>> Thanks >>> >>> - John >>> >> >> > > > -- > > - John > -- - John --20cf306f750c2256b204dbd438b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The machine where this error occurred had both OpenJDK and= IBM's Java installed. The only way I have been able to reproduce is by= installing Cassandra with OpenJDK, shutting it down, the starting it back = up with IBM Java. Snappy compression is enabled with OpenJDK so SSTables, i= ncluding for system tables, are created with compression. Then when I start= Cassandra back up with IBM Java, it cannot read those compressed files. Th= is situation only happened as a result of switching JREs which is not too l= ikely for a production deployment. When I install and deploy Cassandra usin= g IBM Java from the get go, tables are created with compression disabled as= expected.

System tables though are in fact created with snappy c= ompression if it is available.

On Fri, May 3, 2013 at 12:35 PM, John Sanda <john.sanda@gmail.com> wrote:
I am still trying to sort t= his out. When I run with Oracle's JRE, it does in fact look like compre= ssion is enabled for system tables.

cqlsh> DESCRIBE TABLE system.schema_columnfamilies ;=

CREATE TABLE schema_columnfamilies (
=A0 keys= pace_name text,
=A0 columnfamily_name text,
=A0 bloom_f= ilter_fp_chance double,
=A0 caching text,
=A0 column_al= iases text,
=A0 comment text,
=A0 compaction_strategy_class text,
<= div>=A0 compaction_strategy_options text,
=A0 comparator text,
=A0 compression_parameters text,
=A0 default_read_consist= ency text,
=A0 default_validator text,
=A0 default_write_consistency te= xt,
=A0 gc_grace_seconds int,
=A0 id int,
=A0= key_alias text,
=A0 key_aliases text,
=A0 key_validato= r text,
=A0 local_read_repair_chance double,
=A0 max_compaction_thre= shold int,
=A0 min_compaction_threshold int,
=A0 popula= te_io_cache_on_flush boolean,
=A0 read_repair_chance double,
=A0 replicate_on_write boolean,
=A0 subcomparator text,
=A0 type text,
=A0 value_alias text,
=A0 PRIMARY KEY (= keyspace_name, columnfamily_name)
) WITH
=A0 bloom_filt= er_fp_chance=3D0.010000 AND
=A0 caching=3D'KEYS_ONLY' AND
=A0 comment=3D'Col= umnFamily definitions' AND
=A0 dclocal_read_repair_chance=3D0= .000000 AND
=A0 gc_grace_seconds=3D8640 AND
=A0 read_re= pair_chance=3D0.000000 AND
=A0 replicate_on_write=3D'true' AND
=A0 populate_io_= cache_on_flush=3D'false' AND
=A0 compaction=3D{'class= ': 'SizeTieredCompactionStrategy'} AND
=A0 compressio= n=3D{'sstable_compression': 'SnappyCompressor'};


Unfortunately the Cassandra instan= ce that was running with IBM Java was on a test virtual machine that has se= en 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 t= o load the native snappy library. CFMetadata.DEFAULT_COMPRESSOR should be n= ull when snappy is not available.


On Fri, May 3, 2013 at 11:00 AM, Edward Capriolo <edl= inuxguru@gmail.com> wrote:
I did not know the system t= ables were compressed. That would seem like an odd decision you would think= that the system tables are small and would not benefit from compression mu= ch. Is it a static object static object that requires initialization even t= hough 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 th= e 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 nativ= e library fails to load. The error I get looks like,

ERROR [SSTa=
bleBatchOpen:1] 2013-05-02 14:42:42,485 CassandraDaemon.java (line 132) Exc=
eption 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(Comp=
ressionMetadata.java:63)
        at org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.com=
plete(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(SSTableReade=
r.java:238)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja=
va:482)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:34=
5)
        at java.util.concurrent.FutureTask.run(FutureTask.java:177)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExec=
utor.java:1156)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe=
cutor.java:626)
        at java.lang.Thread.run(Thread.java:780)
Caused by: org.apache.cassandra.exceptions.ConfigurationException: SnappyCo=
mpressor.create() threw an error: java.lang.NoClassDefFoundError org.xerial=
.snappy.Snappy (initialization failure)
        at org.apache.cassandra.io.compress.CompressionParameters.createCom=
pressor(CompressionParameters.java:179)
        at org.apache.cassandra.io.compress.CompressionParameters.<init&=
gt;(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(NativeMethodAccessor=
Impl.java:88)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod=
AccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:613)
        at org.apache.cassandra.io.compress.CompressionParameters.createCom=
pressor(CompressionParameters.java:156)
        ... 14 more
Caused by: java.lang.NoClassDefFoundError: org.xerial.snappy.Snappy (initia=
lization failure)
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:176)
        at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyC=
ompressor.java:45)
        ... 19 more
Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] n=
ull
        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(CassandraDaem=
on.java:150)
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraD=
aemon.java:366)
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemo=
n.java:409)




<= /div>--

- John



--

- John
--20cf306f750c2256b204dbd438b7--