Ondřej Černoš created CASSANDRA-5390: ----------------------------------------
Summary: Cassandra doesn't respect internode compression settings Key: CASSANDRA-5390 URL: https://issues.apache.org/jira/browse/CASSANDRA-5390 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Environment: $ /etc/alternatives/jre_1.6.0/bin/java -version java version "1.6.0_23" Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) $ uname -a Linux hostname 2.6.32-358.2.1.el6.x86_64 #1 SMP Tue Mar 12 14:18:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release Scientific Linux release 6.3 (Carbon) $ facter | grep ec2 ... ec2_placement => availability_zone=us-east-1d ... $ rpm -qi cassandra cassandra-1.2.3-1.el6.cmp1.noarch (custom built rpm from cassandra tarball distribution) Reporter: Ondřej Černoš Priority: Critical I run into strange SSL/snappy errors in my multipledatacenter setup. (More on that in related issue). During debugging the issue I switched the internode communication compression off: {noformat} ~ grep internode_compression /etc/cassandra/cassandra.yaml # internode_compression controls whether traffic between nodes is internode_compression: none {noformat} on all nodes in both datacenters. However I still get the very same exception with snappy in the stacktrace and compression error message: {noformat} 2013-03-27 14:06:03.605+0100 [Thread-146] [DEBUG] IncomingTcpConnection.java(91) org.apache.cassandra.net.IncomingTcpConnection: component=c4 IOException reading from socket; closing java.io.IOException: FAILED_TO_UNCOMPRESS(5) at org.xerial.snappy.SnappyNative.throw_error(SnappyNative.java:78) at org.xerial.snappy.SnappyNative.rawUncompress(Native Method) at org.xerial.snappy.Snappy.rawUncompress(Snappy.java:391) at org.apache.cassandra.io.compress.SnappyCompressor.uncompress(SnappyCompressor.java:93) at org.apache.cassandra.streaming.compress.CompressedInputStream.decompress(CompressedInputStream.java:101) at org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:79) at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:320) at org.apache.cassandra.utils.BytesReadTracker.readUnsignedShort(BytesReadTracker.java:140) at org.apache.cassandra.utils.ByteBufferUtil.readShortLength(ByteBufferUtil.java:361) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:371) at org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:160) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) {noformat} The exception is raised from this snappy cpp code: {code} JNIEXPORT jint JNICALL Java_org_xerial_snappy_SnappyNative_rawUncompress__Ljava_lang_Object_2IILjava_lang_Object_2I (JNIEnv * env, jobject self, jobject input, jint inputOffset, jint inputLength, jobject output, jint outputOffset) { char* in = (char*) env->GetPrimitiveArrayCritical((jarray) input, 0); char* out = (char*) env->GetPrimitiveArrayCritical((jarray) output, 0); if(in == 0 || out == 0) { // out of memory throw_exception(env, self, 4); return 0; } size_t uncompressedLength; snappy::GetUncompressedLength(in + inputOffset, (size_t) inputLength, &uncompressedLength); bool ret = snappy::RawUncompress(in + inputOffset, (size_t) inputLength, out + outputOffset); env->ReleasePrimitiveArrayCritical((jarray) input, in, 0); env->ReleasePrimitiveArrayCritical((jarray) output, out, 0); if(!ret) { throw_exception(env, self, 5); return 0; } return (jint) uncompressedLength; } {code} Which looks like the communication was still compressed, or at least Cassandra tried to decompress the stream. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira