Re: "no snappyjava in java.library.path" (JDK 1.7 issue?)
Reverting to JDK 1.6 appears to fix the issue. Is JDK 1.7 not yet supported by Cassandra? java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) On Tue, May 15, 2012 at 12:55 PM, Stephen McKamey wrote: > Worth noting is I'm on Mac OS X 10.7.4 and I recently upgraded to the > latest JDK (really hoping this isn't the issue): > > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b21) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) > >
"no snappyjava in java.library.path" (JDK 1.7 issue?)
I'm getting a org.xerial.snappy.SnappyError when creating my first column family after blowing away my Cassandra installation and trying to run the latest release. I'm undoubtably making some silly mistake but cannot seem to find it. I even commented out my "sstable_compression=SnappyCompressor" settings. InvalidRequestException(why:SnappyCompressor.create() threw an error: org.xerial.snappy.SnappyError [FAILED_TO_LOAD_NATIVE_LIBRARY] null) at org.apache.cassandra.thrift.Cassandra$system_add_column_family_result.read(Cassandra.java:27683) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) at org.apache.cassandra.thrift.Cassandra$Client.recv_system_add_column_family(Cassandra.java:1193) at org.apache.cassandra.thrift.Cassandra$Client.system_add_column_family(Cassandra.java:1180) at org.scale7.cassandra.pelops.ColumnFamilyManager$2.execute(ColumnFamilyManager.java:64) at org.scale7.cassandra.pelops.ColumnFamilyManager$2.execute(ColumnFamilyManager.java:61) at org.scale7.cassandra.pelops.ManagerOperand.tryOperation(ManagerOperand.java:131) at org.scale7.cassandra.pelops.ColumnFamilyManager.addColumnFamily(ColumnFamilyManager.java:67) Worth noting is I'm on Mac OS X 10.7.4 and I recently upgraded to the latest JDK (really hoping this isn't the issue): java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) When Cassandra starts up with blown away lib/log dirs, I can see the Snappy in the classpath, but it says "Native methods will be disabled" despite having JNA. I've got the latest JNA installed at /usr/share/java/jna.jar and symbolic linked at /opt/apache-cassandra-1.1.0/lib/jna.jar. INFO 12:18:59,430 Logging initialized INFO 12:18:59,434 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0_04 INFO 12:18:59,435 Classpath: bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/apache-cassandra-1.1.0.jar:bin/../lib/apache-cassandra-clientutil-1.1.0.jar:bin/../lib/apache-cassandra-thrift-1.1.0.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.9.2.jar:bin/../lib/jackson-mapper-asl-1.9.2.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.7.0.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/metrics-core-2.0.3.jar:bin/../lib/platform.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/snaptree-0.1.jar:bin/../lib/jamm-0.2.5.jar INFO 12:18:59,710 Unable to link C library. Native methods will be disabled. INFO 12:19:00,529 Cassandra version: 1.1.0
EC2 Maintenance Reboot
I just received an email from AWS about rebooting my EC2 instance for maintenance. Thankfully this is just my webhead, but I'm curious have others experienced this with a Cassandra instance? http://aws.amazon.com/maintenance-help/ The details seem to say that if you allow them to do the reboot for you then your instance data will remain intact (as opposed to if you do it yourself). Has anyone experienced this to verify? Thanks, Stephen
Cluster properties via Thrift?
Is there any way to initialize via thrift cluster configuration properties (e.g., partitioner)? Do you always have to set these values via the cassandra.yaml file? I'm trying to programmatically build out all of my schema so that I can build out a fresh install just by running the app.
Expiring Columns
I'm curious about Expiring Columns. Say I create a Column Family where *all* of the Columns are set to be expiring columns. When a row's entire set of columns have expired, will an empty row it sill be returned in range queries? Or will it just be nicely compacted away?
RE: batch_mutate failed: out of sequence response
[I wrote this Apr 10, 2011 at 12:09 but my message seems to have gotten lost along the way.] I use Pelops (the 1.0-0.7.x build from the Github Maven repo) and have occasionally seen this message (under load or during GC). I have a test app running in two separate single-threaded processes doing a slow trickle insert into a single Cassandra 0.7.4 node all on the same box (Mac OS X). This has been running off and on for over a week with no exceptions and I just this same error about two hours ago. Both client processes experienced it at about the same time, and it seemed related to a GC/compaction on the Cassandra instance. I'm guessing that it is either actually a read timeout on the clients, or (less likely) somehow the Cassandra instance mixed up the two responses? On Fri, Apr 8 2011 at 07:28, Dan Washusen wrote: > Dan Hendry mentioned that he sees these errors. Is he also using Pelops? > From his comment about retrying I'd assume not... > > -- > Dan Washusen > > On Thursday, 7 April 2011 at 7:39 PM, Héctor Izquierdo Seliva wrote: > > El mié, 06-04-2011 a las 21:04 -0500, Jonathan Ellis escribió: > > "out of sequence response" is thrift's way of saying "I got a response > for request Y when I expected request X." > > my money is on using a single connection from multiple threads. don't do > that. > > > I'm not using thrift directly, and my application is single thread, so I > guess this is Pelops fault somehow. Since I managed to tame memory > comsuption the problem has not appeared again, but it always happened > during a stop-the-world GC. Could it be that the message was sent > instead of being dropped by the server when the client assumed it had > timed out? > >
