I had this error as well some time ago. It was due to the noexec mount flag of
the tmp directory. Worked again when I removed that flag from the tmp directory.
Cheers
--
Jan Schmidle
Founder & CEO
P+49 89 999540-41
mschmi...@cospired.com
cospired GmbH
Roßmarkt 6
D-80331 Munich
P+49 89 999540
Yes it does, the stack trace is in the first thread. I did not try to
create CF (was trying to enable it in cassandra.yaml), I have an existing
CF and wanted to use compression for inter-node communication. When I
enable snappy compression (in yaml) I get the error and cassandra quits. I
figured th
IIRC there is a test for snappy when the node starts does that log an error ?
And / or can you create a CF that uses snappy compression (it was the default
for a while in 1.2).
Cheers
-
Aaron Morton
New Zealand
@aaronmorton
Co-Founder & Principal Consultant
Apache Cassandra C
Thanks Christopher !
I don't think glibc is an issue (as it did go that far) /usr/tmp/
snappy-1.0.5-libsnappyjava.so is not there, permissions look ok, are there
any special settings (like JVM args) that I should be using ? I can see
libsnappyjava.so in the jar though
(snappy-java-1.0.5.jar\org\xer
I had this the other day when we were accidentally provisioned a centos5
machine (instead of 6). Think it relates to the version of glibc. Notice it
wants the native binary .so not the .jar
So maybe update to a newer version of glibc? Or possibly make sure the .so
exists at /usr/tmp/snappy-1.0.
