xerial / snappy-java

Snappy compressor/decompressor for Java

snappy-java

snappy-java is a Java port of the snappy, a fast C++ compresser/decompresser developed by Google.

Features

• Fast compression/decompression around 200~400MB/sec.
• Less memory usage. SnappyOutputStream uses only 32KB+ in default.
• JNI-based implementation to achieve comparable performance to the native C++ version.
  • Although snappy-java uses JNI, it can be used safely with multiple class loaders (e.g. Tomcat, etc.).
• Compression/decompression of Java primitive arrays (float[], double[], int[], short[], long[], etc.)
  • To improve the compression ratios of these arrays, you can use a fast data-rearrangement implementation (BitShuffle) before compression
• Portable across various operating systems; Snappy-java contains native libraries built for Window/Mac/Linux, etc. snappy-java loads one of these libraries according to your machine environment (It looks system properties, os.name and os.arch).
• Simple usage. Add the snappy-java-(version).jar file to your classpath. Then call compression/decompression methods in org.xerial.snappy.Snappy.
• Framing-format support (Since 1.1.0 version)
• OSGi support
• Apache License Version 2.0. Free for both commercial and non-commercial use.

Performance

• Snappy's main target is very high-speed compression/decompression with reasonable compression size. So the compression ratio of snappy-java is modest and about the same as LZF (ranging 20%-100% according to the dataset).

• Here are some benchmark results, comparing snappy-java and the other compressors LZO-java/LZF/QuickLZ/Gzip/Bzip2. Thanks Tatu Saloranta @cotowncoder for providing the benchmark suite.

• The benchmark result indicates snappy-java is the fastest compressor/decompressor in Java: https://ning.github.io/jvm-compressor-benchmark/results/canterbury-roundtrip-2011-07-28/index.html

• The decompression speed is twice as fast as the others: https://ning.github.io/jvm-compressor-benchmark/results/canterbury-uncompress-2011-07-28/index.html

Download

• Release Notes

The current stable version is available from here:

• Release version: https://repo1.maven.org/maven2/org/xerial/snappy/snappy-java/
• Snapshot version (the latest beta version): https://oss.sonatype.org/content/repositories/snapshots/org/xerial/snappy/snappy-java/

Using with Maven

Snappy-java is available from Maven's central repository. Add the following dependency to your pom.xml:

<dependency>
  <groupId>org.xerial.snappy</groupId>
  <artifactId>snappy-java</artifactId>
  <version>(version)</version>
  <type>jar</type>
  <scope>compile</scope>
</dependency>

Using with sbt

libraryDependencies += "org.xerial.snappy" % "snappy-java" % "(version)"

Usage

First, import org.xerial.snapy.Snappy in your Java code:

import org.xerial.snappy.Snappy;

Then use Snappy.compress(byte[]) and Snappy.uncompress(byte[]):

String input = "Hello snappy-java! Snappy-java is a JNI-based wrapper of "
     + "Snappy, a fast compresser/decompresser.";
byte[] compressed = Snappy.compress(input.getBytes("UTF-8"));
byte[] uncompressed = Snappy.uncompress(compressed);

String result = new String(uncompressed, "UTF-8");
System.out.println(result);

In addition, high-level methods (Snappy.compress(String), Snappy.compress(float[] ..) etc. ) and low-level ones (e.g. Snappy.rawCompress(.. ), Snappy.rawUncompress(..), etc.), which minimize memory copies, can be used.

Stream-based API

Stream-based compressor/decompressor SnappyOutputStream/SnappyInputStream are also available for reading/writing large data sets. SnappyFramedOutputStream/SnappyFramedInputStream can be used for the framing format.

• See also Javadoc API

Compatibility Notes

The original Snappy format definition did not define a file format. It later added a "framing" format to define a file format, but by this point major software was already using an industry standard instead -- represented in this library by the SnappyOutputStream and SnappyInputStream methods.

For interoperability with other libraries, check that compatible formats are used. Note that not all libraries support all variants.

• SnappyOutputStream and SnappyInputStream use [magic header:16 bytes]([block size:int32][compressed data:byte array])* format. You can read the result of Snappy.compress with SnappyInputStream, but you cannot read the compressed data generated by SnappyOutputStream with Snappy.uncompress.
• SnappyHadoopCompatibleOutputStream does not emit a file header but write out the current block size as a preemble to each block

Data format compatibility matrix:

Write\Read	Snappy.uncompress	SnappyInputStream	SnappyFramedInputStream	org.apache.hadoop.io.compress.SnappyCodec
Snappy.compress	ok	ok	x	x
SnappyOutputStream	x	ok	x	x
SnappyFramedOutputStream	x	x	ok	x
SnappyHadoopCompatibleOutputStream	x	x	x	ok

BitShuffle API (Since 1.1.3-M2)

BitShuffle is an algorithm that reorders data bits (shuffle) for efficient compression (e.g., a sequence of integers, float values, etc.). To use BitShuffle routines, import org.xerial.snapy.BitShuffle:

import org.xerial.snappy.BitShuffle;

int[] data = new int[] {1, 3, 34, 43, 34};
byte[] shuffledByteArray = BitShuffle.shuffle(data);
byte[] compressed = Snappy.compress(shuffledByteArray);
byte[] uncompressed = Snappy.uncompress(compressed);
int[] result = BitShuffle.unshuffleIntArray(uncompress);

System.out.println(result);

Shuffling and unshuffling of primitive arrays (e.g., short[], long[], float[], double[], etc.) are supported. See Javadoc for the details.

Setting classpath

If you have snappy-java-(VERSION).jar in the current directory, use -classpath option as follows:

$ javac -classpath ".;snappy-java-(VERSION).jar" Sample.java  # in Windows
or
$ javac -classpath ".:snappy-java-(VERSION).jar" Sample.java  # in Mac or Linux

Public discussion group

Post bug reports or feature request to the Issue Tracker: https://github.com/xerial/snappy-java/issues

Public discussion forum is here: Xerial Public Discussion Group

For developers

snappy-java uses sbt (simple build tool for Scala) as a build tool. Here is a simple usage

$ ./sbt            # enter sbt console
> ~test            # run tests upon source code change
> ~testOnly        # run tests that matches a given name pattern  
> publishM2        # publish jar to $HOME/.m2/repository
> package          # create jar file
> findbugs         # Produce findbugs report in target/findbugs
> jacoco:cover     # Report the code coverage of tests to target/jacoco folder    

If you need to see detailed debug messages, launch sbt with -Dloglevel=debug option:

$ ./sbt -Dloglevel=debug

For the details of sbt usage, see my blog post: Building Java Projects with sbt

Building from the source code

See the build instruction. Building from the source code is an option when your OS platform and CPU architecture is not supported. To build snappy-java, you need Git, JDK (1.6 or higher), g++ compiler (mingw in Windows) etc.

$ git clone https://github.com/xerial/snappy-java.git
$ cd snappy-java
$ make

When building on Solaris, use gmake:

$ gmake

A file target/snappy-java-$(version).jar is the product additionally containing the native library built for your platform.

Creating a new release

GitHub action [https://github.com/xerial/snappy-java/blob/master/.github/workflows/release.yml] will publish a new relase to Maven Central (Sonatype) when a new tag vX.Y.Z is pushed.

Miscellaneous Notes

Using snappy-java with Tomcat 6 (or higher) Web Server

Simply put the snappy-java's jar to WEB-INF/lib folder of your web application. Usual JNI-library specific problem no longer exists since snappy-java version 1.0.3 or higher can be loaded by multiple class loaders.

Configure snappy-java using property file

Prepare org-xerial-snappy.properties file (under the root path of your library) in Java's property file format. Here is a list of the available properties:

• org.xerial.snappy.lib.path (directory containing a snappyjava's native library)
• org.xerial.snappy.lib.name (library file name)
• org.xerial.snappy.tempdir (temporary directory to extract a native library bundled in snappy-java)
• org.xerial.snappy.use.systemlib (if this value is true, use system installed libsnappyjava.so looking the path specified by java.library.path)

---

Snappy-java is developed by Taro L. Saito. Twitter @taroleo

snappy-java's Issues

Prepare g++ compiler compiled with -fPIC.

It is necessary for building linux-x86_64 native lib.

Need support for SunOS

Hi, I have this error when I run cassandra on my server:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)
at org.xerial.snappy.Snappy.(Snappy.java:44)
at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:46)
at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:56)
at org.apache.cassandra.io.compress.SnappyCompressor.(SnappyCompressor.java:38)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:76)
at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:84)
at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:438)
at org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:114)
at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:127)
at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:389)
at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
... 17 more

I've realised that snappy-java doesn't have native library for SunOS.

Is it possible to compile it for this OS ?

My System.properties:
os.arch=amd64
os.name=SunOS
os.version=5.10

snappy-java-1.0.5

Please describe a summary of the new feature (in a paragraph):
Build a new version

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=40

---

earlier comments

robert.stupp said, at 2012-05-31T21:52:56.000Z:

Feature request: Make snappy usable in JBoss AS 7 applications - including hot re-deplyment - including support for multiple EARs using snappy

No support for Power architecture

Getting the following error when using snappy-java on a power architecture machine since there is no libsnappyjava.so for ppc64.

[FAILED_TO_LOAD_NATIVE_LIBRARY] null 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)

PPC typo in OSInfo

archMapping.put("pwoer", PPC);

I think should be

archMapping.put("power", PPC);

Jar Checksum in Maven is wrong

When trying to install dependencies for a clojure project, which depends on snappy-java I'm getting:

Retrieving org/xerial/snappy/snappy-java/1.0.4.1/snappy-java-1.0.4.1.jar 
    from http://repo1.maven.org/maven2/
Checksum validation failed, expected f88b89a5a21a466aeb0ecf0c063605bd584b4947 but is f2592c37e6b80bb210794466cfcf8eed013a711c
Retrieving org/xerial/snappy/snappy-java/1.0.4.1/snappy-java-1.0.4.1.jar 
    from http://repo1.maven.org/maven2/
Could not transfer artifact org.xerial.snappy:snappy-java:jar:1.0.4.1 from/to central (http://repo1.maven.org/maven2): Checksum validation failed, expected f88b89a5a21a466aeb0ecf0c063605bd584b4947 but is f2592c37e6b80bb210794466cfcf8eed013a711c
Could not find artifact org.xerial.snappy:snappy-java:jar:1.0.4.1 in clojars (https://clojars.org/repo/)
Check :dependencies and :repositories for typos.
It's possible the specified jar is not in any repository.
If so, see "Free-floating Jars" under http://j.mp/repeatability
Could not resolve dependencies

Snap/Unsnap CUI command

Please describe a summary of the new feature (in a paragraph):

Add snap and unsnap CUI command for compression and decompression.

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=16

effects of classloader injection and multiple wars in servlet container

What happens if multiple wars in the same tomcat instance contain snappy-java? It would appear that would require that each contain the same version of snappy-java (at least the jni interface must be the same).

Would a better solution to the library problems in a jee environment be to modify the name of the library for each class loader? So in the process of SnappyLoader.loadNativeLibrary method, copy the os/arch specific library to a temp file with a modified name (i.e. libsnappyjava1234.so). Then for that class loader make a static call to System.load(snappyjava1234). The same library may end up being loaded multiple times in the same container, but there will never be any issue with different versions.

Sign jar with gpg

Signing packages with GPG is mandatory for deploying to Sonatype repository:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Create github pages for snappy-java

OpenBSD native libs for 1.0.5-M2

Hi, I'm an OpenBSD developer and have created the OpenBSD native libs for both i386 and amd64. Please add them to src/main/resources/org/xerial/snappy/native/OpenBSD. The native libs can be downloaded here:

http://www.intricatesoftware.com/distfiles/snappy-java-1.0.5-M2-openbsd.zip

All the tests pass on both amd64 and i386:
Tests run: 39, Failures: 0, Errors: 0, Skipped: 0

Thank you,
-Kurt
[email protected]

jre version

It appears that the current version is being built requires the 1.6 jre. The 1.0.x line required 1.5 (as I recall). When did the dependency on 1.6 get introduced? Should that have been a major version change (requiring a new jre version is pretty non-passive)?

Now that 1.6 is being used, in SnappyLoader where the copied file is being chmod to 777, should the new File methods to set these properties (added in 1.6) be used instead?

Native part does not load with sample jar classloader with native support

Hi,

I'm not able to run snappy from a very sample project using a jar classloader.
the native part does not load.

If I remove the native parent classloader stuff from snappy and let the jar classloader load the native lib, it's working.

I can't find a good solution to solve the problem by myself without breaking your classloader part.

Here his the sample java project runnable with CLI :
https://github.com/n0rad/bootstrap/tree/master/sample/jar-sample

And the main class :
https://github.com/n0rad/bootstrap/blob/master/sample/jar-sample/src/main/java/fr/norad/boostrap/sample/jar/Main.java

Jansi native stuff load well but not snappy.

Can you help me on it ?

[FAILED_TO_LOAD_NATIVE_LIBRARY] null

Hi, I'm getting this error for snappy-java library:

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)

This is only happening on my remote development server:

Windows 7 Pro SP1 64bit
Tomcat v6.0.36
snappy-java.jar is under TOMCAT/lib and not part of my war

I have also tried to remove it from TOMCAT/lib and make it as part of war
And I have tried with versions: 1.0.4.1, 1.0.4-M2, 1.0.4-M5 and1.1.0-M3

I also tried locally with the following settings and worked just fine

Win7 Pro SP1 32bit
Tomcat v6.0.36
Jetty 6.1.26
snappy-java-1.1.0-M3.jar under TOMCAT/lib and not part of my war

The only difference here seems to be the machine type from 64 bit to 32 bit.

Is there something I'm missing?

Thanks on advance your comments.

Assign unique file names to the extracted native libraries

In the discussion of #24, it becomes clear that if we use a different library file name for each class loader, no name collision of library functions occurs, at least in Oracle JVM.

I tested this approach in xerial:larray project, and it works good. So the current native code injection technique in snappy-java can be safely replaced.

Snappy Java failed to during execution on raspberry-pi

Hi When i was trying to use snappy-java on raspberry pi with cassandra.

I downloaded the latest version of your library where the binary for armhf are present and it crashes (I also tried to crosscompile it myself but with the same result)

A fatal error has been detected by the Java Runtime Environment:

SIGILL (0x4) at pc=0xa4e10254, pid=13720, tid=3058377840

JRE version: Java(TM) SE Runtime Environment (8.0)

Java VM: Java HotSpot(TM) Client VM (25.0-b04 mixed mode linux-arm )

Problematic frame:

C [snappy-1.0.5-libsnappyjava.so+0x1254] _init+0x223

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

If you would like to submit a bug report, please visit:

http://bugreport.sun.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

--------------- T H R E A D ---------------

Current thread (0x01b6ad30): JavaThread "main" [_thread_in_native, id=13754, stack(0xb6486000,0xb64b3000)]

siginfo:si_signo=SIGILL: si_errno=0, si_code=1 (ILL_ILLOPC), si_addr=0xa4e10254

Registers:
r0 = 0x0000001c
r1 = 0xbe804044
r2 = 0x0000007c
r3 = 0x00000000
r4 = 0x0000001c
r5 = 0xbe804044
r6 = 0x01eda6a0
r7 = 0x01bd1b78
r8 = 0xbe804044
r9 = 0xb6fe1048
r10 = 0x0000001c
fp = 0xb64af52c
r12 = 0xb6f5bcf8
sp = 0xb64af470
lr = 0xa4e10037
pc = 0xa4e10254
cpsr = 0xa0000030

Top of Stack: (sp=0xb64af470)
0xb64af470: a4e10031 b6fca210 01bd1b78 00000001
0xb64af480: 00000000 01eda6a0 01bd1b78 be804044
0xb64af490: 0000001c b6fca36c 01eda6a0 b6fdd400
0xb64af4a0: 01eda7fc b6fe1048 00000006 00000006
0xb64af4b0: 00000009 b6fce3bc 00000001 b6fe1094
0xb64af4c0: 01eda6a0 01ee20a0 80000000 00000000
0xb64af4d0: 00000000 b64af4b0 00000000 0000cef8
0xb64af4e0: 01eda6a0 b64af4b8 b64af4c8 b64af4c8

Instructions: (pc=0xa4e10254)
0xa4e10234: f7ff4038 bf00bf85 0000be9e 0000bddc
0xa4e10244: 0000008c 00000098 4a044b03 589b447b
0xa4e10254: f7ffb10b 4770bf07 0000bdac 0000007c
0xa4e10264: b5084a09 4b09447a 447b7812 4a08b95a

Register to memory mapping:

r0 = 0x0000001c
0x0000001c is an unknown value

r1 = 0xbe804044
0xbe804044 is an unknown value

r2 = 0x0000007c
0x0000007c is an unknown value

r3 = 0x00000000
0x00000000 is an unknown value

r4 = 0x0000001c
0x0000001c is an unknown value

r5 = 0xbe804044
0xbe804044 is an unknown value

r6 = 0x01eda6a0
0x01eda6a0 is an unknown value

r7 = 0x01bd1b78
0x01bd1b78 is an unknown value

r8 = 0xbe804044
0xbe804044 is an unknown value

r9 = 0xb6fe1048
0xb6fe1048: _rtld_global+0 in /lib/ld-linux-armhf.so.3 at 0xb6fbb000

r10 = 0x0000001c
0x0000001c is an unknown value

fp = 0xb64af52c
0xb64af52c is pointing into the stack for thread: 0x01b6ad30

r12 = 0xb6f5bcf8
0xb6f5bcf8: <offset 0x12bcf8> in /lib/arm-linux-gnueabihf/libc.so.6 at 0xb6e30000

sp = 0xb64af470
0xb64af470 is pointing into the stack for thread: 0x01b6ad30

lr = 0xa4e10037
0xa4e10037: <offset 0x1037> in /tmp/snappy-1.0.5-libsnappyjava.so at 0xa4e0f000

pc = 0xa4e10254
0xa4e10254: <offset 0x1254> in /tmp/snappy-1.0.5-libsnappyjava.so at 0xa4e0f000

Stack: [0xb6486000,0xb64b3000], sp=0xb64af470, free space=165k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [snappy-1.0.5-libsnappyjava.so+0x1254] _init+0x223

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0
j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+302
j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+48
j java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57
j java.lang.System.load(Ljava/lang/String;)V+7
j org.xerial.snappy.SnappyNativeLoader.load(Ljava/lang/String;)V+29
v ~StubRoutines::call_stub
j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+57
j org.xerial.snappy.SnappyLoader.loadNativeLibrary(Ljava/lang/Class;)V+55
j org.xerial.snappy.SnappyLoader.load()Ljava/lang/Object;+21
j org.xerial.snappy.Snappy.()V+0
v ~StubRoutines::call_stub
j org.apache.cassandra.io.compress.SnappyCompressor.create(Ljava/util/Map;)Lorg/apache/cassandra/io/compress/SnappyCompressor;+0
j org.apache.cassandra.io.compress.SnappyCompressor.isAvailable()Z+3
j org.apache.cassandra.io.compress.SnappyCompressor.()V+19
v ~StubRoutines::call_stub
j org.apache.cassandra.config.CFMetaData.()V+47
v ~StubRoutines::call_stub
j org.apache.cassandra.config.KSMetaData.systemKeyspace()Lorg/apache/cassandra/config/KSMetaData;+7
j org.apache.cassandra.config.DatabaseDescriptor.loadYaml()V+2241
j org.apache.cassandra.config.DatabaseDescriptor.()V+52
v ~StubRoutines::call_stub
j org.apache.cassandra.service.CassandraDaemon.setup()V+248
j org.apache.cassandra.service.CassandraDaemon.activate()V+7
j org.apache.cassandra.service.CassandraDaemon.main([Ljava/lang/String;)V+3
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x01edb090 JavaThread "process reaper" daemon [_thread_blocked, id=13779, stack(0xa4e1d000,0xa4e2c000)]
0x01ec8ec0 JavaThread "EXPIRING-MAP-REAPER:1" daemon [_thread_blocked, id=13773, stack(0xa4c79000,0xa4ca6000)]
0x01ec6608 JavaThread "ScheduledTasks:1" daemon [_thread_blocked, id=13772, stack(0xa4ca6000,0xa4cd3000)]
0x01ec4580 JavaThread "metrics-meter-tick-thread-2" daemon [_thread_blocked, id=13771, stack(0xa4cd3000,0xa4d00000)]
0x01e909b8 JavaThread "metrics-meter-tick-thread-1" daemon [_thread_blocked, id=13770, stack(0xa4e2c000,0xa4e59000)]
0x01d34368 JavaThread "FileWatchdog" daemon [_thread_blocked, id=13769, stack(0xa4f59000,0xa4f86000)]
0x01cfdc10 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=13767, stack(0xa5006000,0xa5033000)]
0x01ceee58 JavaThread "RMI TCP Accept-7199" daemon [_thread_in_native, id=13766, stack(0xa5036000,0xa5063000)]
0x01ce5260 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=13765, stack(0xa5063000,0xa5090000)]
0x01c41048 JavaThread "Service Thread" daemon [_thread_blocked, id=13762, stack(0xa5206000,0xa5233000)]
0x01c3c7c0 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=13761, stack(0xa5233000,0xa52b3000)]
0x01be5770 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=13760, stack(0xa5354000,0xa5381000)]
0x01be3da0 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=13759, stack(0xa5381000,0xa53ae000)]
0x01bcbb40 JavaThread "Finalizer" daemon [_thread_blocked, id=13758, stack(0xa5525000,0xa5552000)]
0x01bc9030 JavaThread "Reference Handler" daemon [_thread_blocked, id=13757, stack(0xa5552000,0xa557f000)]
=>0x01b6ad30 JavaThread "main" [_thread_in_native, id=13754, stack(0xb6486000,0xb64b3000)]

Other Threads:
0x01bc6b98 VMThread [stack: 0xa557f000,0xa55ff000] [id=13756]
0x01cff770 WatcherThread [stack: 0xa4f86000,0xa5006000] [id=13768]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 49792K, used 39069K [0xa5f20000, 0xa9520000, 0xa9520000)
eden space 44288K, 88% used [0xa5f20000, 0xa8547538, 0xa8a60000)
from space 5504K, 0% used [0xa8a60000, 0xa8a60000, 0xa8fc0000)
to space 5504K, 0% used [0xa8fc0000, 0xa8fc0000, 0xa9520000)
concurrent mark-sweep generation total 168960K, used 0K [0xa9520000, 0xb3a20000, 0xb3b20000)
Metaspace total 7886K, used 7752K, reserved 10240K
data space 6970K, used 6912K, reserved 8192K
class space 916K, used 839K, reserved 2048K

Card table byte_map: [0xa5eb1000,0xa5f20000] byte_map_base: 0xa5981700

Polling page: 0xb6fdb000

Code Cache [0xb3db5000, 0xb3ead000, 0xb5db5000)
total_blobs=467 nmethods=308 adapters=95 free_code_cache=31787Kb largest_free_block=32550016

Compilation events (10 events):
Event: 13.614 Thread 0x01c3c7c0 30
Event: 13.616 Thread 0x01c3c7c0 nmethod 303 0xb3ea8588 code [0xb3ea8660, 0xb3ea8728]
Event: 13.616 Thread 0x01c3c7c0 30
Event: 13.617 Thread 0x01c3c7c0 nmethod 304 0xb3ea8788 code [0xb3ea8860, 0xb3ea8928]
Event: 13.624 Thread 0x01c3c7c0 30
Event: 13.625 Thread 0x01c3c7c0 nmethod 305 0xb3ea8988 code [0xb3ea8a60, 0xb3ea8b18]
Event: 13.625 Thread 0x01c3c7c0 30
Event: 13.627 Thread 0x01c3c7c0 nmethod 306 0xb3ea8b48 code [0xb3ea8c20, 0xb3ea8ce8]
Event: 13.641 Thread 0x01c3c7c0
Event: 13.685 Thread 0x01c3c7c0 nmethod 2% 0xb3ea8d48 code [0xb3ea8f20, 0xb3ea9848]

GC Heap History (0 events):
No events

Deoptimization events (0 events):
No events

Internal exceptions (10 events):
Event: 13.255 Thread 0x01b6ad30 Threw 0xa82a2150 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.262 Thread 0x01b6ad30 Threw 0xa82ae7b0 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.268 Thread 0x01b6ad30 Threw 0xa8390470 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.272 Thread 0x01b6ad30 Threw 0xa8395658 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.277 Thread 0x01b6ad30 Threw 0xa8398488 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.289 Thread 0x01b6ad30 Threw 0xa83ad530 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.310 Thread 0x01b6ad30 Threw 0xa83bb500 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.334 Thread 0x01b6ad30 Threw 0xa83ccf18 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.336 Thread 0x01b6ad30 Threw 0xa83cffe8 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168
Event: 13.397 Thread 0x01b6ad30 Threw 0xa83f5048 at /HUDSON/workspace/2-build-linux-arm-hflt/jdk8-profile-gp/2071/hotspot/src/share/vm/prims/jvm.cpp:1168

Events (10 events):
Event: 13.519 loading class 0xa5193358
Event: 13.520 loading class 0xa5193358 done
Event: 13.531 loading class 0xa5864560
Event: 13.532 loading class 0xa5864560 done
Event: 13.533 loading class 0xa5193320
Event: 13.533 loading class 0xa5193320 done
Event: 13.540 loading class 0x01edb428
Event: 13.541 loading class 0x01edb428 done
Event: 13.543 loading class 0x01edc0c0
Event: 13.543 loading class 0x01edc0c0 done

Dynamic libraries:
00008000-00009000 r-xp 00000000 b3:02 131082 /usr/local/bin/java/bin/java
00010000-00011000 rw-p 00000000 b3:02 131082 /usr/local/bin/java/bin/java
01b64000-01f12000 rw-p 00000000 00:00 0 [heap]
a4aac000-a4b66000 r-xp 00000000 b3:02 10848 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17
a4b66000-a4b6d000 ---p 000ba000 b3:02 10848 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17
a4b6d000-a4b71000 r--p 000b9000 b3:02 10848 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17
a4b71000-a4b73000 rw-p 000bd000 b3:02 10848 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17
a4b73000-a4b9a000 rw-p 00000000 00:00 0
a4b9a000-a4c79000 rw-p 00000000 00:00 0
a4c79000-a4c7c000 ---p 00000000 00:00 0
a4c7c000-a4ca6000 rw-p 00000000 00:00 0 [stack:13773]
a4ca6000-a4ca9000 ---p 00000000 00:00 0
a4ca9000-a4cd3000 rw-p 00000000 00:00 0 [stack:13772]
a4cd3000-a4cd6000 ---p 00000000 00:00 0
a4cd6000-a4d00000 rw-p 00000000 00:00 0 [stack:13771]
a4d00000-a4d58000 rw-p 00000000 00:00 0
a4d58000-a4e00000 ---p 00000000 00:00 0
a4e04000-a4e0f000 r--p 00000000 b3:02 70040 /etc/ld.so.cache
a4e0f000-a4e14000 r-xp 00000000 b3:02 28468 /tmp/snappy-1.0.5-libsnappyjava.so
a4e14000-a4e1b000 ---p 00005000 b3:02 28468 /tmp/snappy-1.0.5-libsnappyjava.so
a4e1b000-a4e1c000 r--p 00004000 b3:02 28468 /tmp/snappy-1.0.5-libsnappyjava.so
a4e1c000-a4e1d000 rw-p 00005000 b3:02 28468 /tmp/snappy-1.0.5-libsnappyjava.so
a4e1d000-a4e20000 ---p 00000000 00:00 0
a4e20000-a4e2c000 rw-p 00000000 00:00 0 [stack:13779]
a4e2c000-a4e2f000 ---p 00000000 00:00 0
a4e2f000-a4f42000 rw-p 00000000 00:00 0 [stack:13770]
a4f42000-a4f59000 rw-p 00000000 00:00 0
a4f59000-a4f5c000 ---p 00000000 00:00 0
a4f5c000-a4f86000 rw-p 00000000 00:00 0 [stack:13769]
a4f86000-a4f87000 ---p 00000000 00:00 0
a4f87000-a5006000 rw-p 00000000 00:00 0 [stack:13768]
a5006000-a5009000 ---p 00000000 00:00 0
a5009000-a5033000 rw-p 00000000 00:00 0 [stack:13767]
a5033000-a5036000 r--s 00083000 b3:02 131257 /usr/local/bin/java/jre/lib/ext/localedata.jar
a5036000-a5039000 ---p 00000000 00:00 0
a5039000-a5063000 rw-p 00000000 00:00 0 [stack:13766]
a5063000-a5066000 ---p 00000000 00:00 0
a5066000-a5090000 rw-p 00000000 00:00 0 [stack:13765]
a5090000-a5094000 r--s 0008a000 b3:02 131302 /usr/local/bin/java/jre/lib/jsse.jar
a5094000-a5096000 r--s 0000c000 b3:02 131974 /home/pi/dsc-cassandra-1.2.5/lib/snaptree-0.1.jar
a5096000-a5098000 r--s 00130000 b3:02 131976 /home/pi/dsc-cassandra-1.2.5/lib/snappy-java-1.0.5.jar
a5098000-a509e000 r--s 00033000 b3:02 131936 /home/pi/dsc-cassandra-1.2.5/lib/snakeyaml-1.6.jar
a509e000-a50a0000 r--s 00001000 b3:02 131978 /home/pi/dsc-cassandra-1.2.5/lib/slf4j-log4j12-1.7.2.jar
a50a0000-a50b6000 r--s 000fe000 b3:02 131983 /home/pi/dsc-cassandra-1.2.5/lib/netty-3.5.9.Final.jar
a50b6000-a50bf000 r--s 0006d000 b3:02 131980 /home/pi/dsc-cassandra-1.2.5/lib/log4j-1.2.16.jar
a50bf000-a50cc000 r-xp 00000000 b3:02 131228 /usr/local/bin/java/jre/lib/arm/libnio.so
a50cc000-a50d3000 ---p 0000d000 b3:02 131228 /usr/local/bin/java/jre/lib/arm/libnio.so
a50d3000-a50d4000 rw-p 0000c000 b3:02 131228 /usr/local/bin/java/jre/lib/arm/libnio.so
a50d4000-a50e7000 r-xp 00000000 b3:02 131227 /usr/local/bin/java/jre/lib/arm/libnet.so
a50e7000-a50ef000 ---p 00013000 b3:02 131227 /usr/local/bin/java/jre/lib/arm/libnet.so
a50ef000-a50f0000 rw-p 00013000 b3:02 131227 /usr/local/bin/java/jre/lib/arm/libnet.so
a50f0000-a50f8000 r-xp 00000000 b3:02 131225 /usr/local/bin/java/jre/lib/arm/libmanagement.so
a50f8000-a50ff000 ---p 00008000 b3:02 131225 /usr/local/bin/java/jre/lib/arm/libmanagement.so
a50ff000-a5100000 rw-p 00007000 b3:02 131225 /usr/local/bin/java/jre/lib/arm/libmanagement.so
a5100000-a51fc000 rw-p 00000000 00:00 0
a51fc000-a5200000 ---p 00000000 00:00 0
a5201000-a5203000 r--s 00005000 b3:02 131933 /home/pi/dsc-cassandra-1.2.5/lib/slf4j-api-1.7.2.jar
a5203000-a5206000 r--s 00011000 b3:02 131992 /home/pi/dsc-cassandra-1.2.5/lib/metrics-core-2.0.3.jar
a5206000-a5209000 ---p 00000000 00:00 0
a5209000-a5233000 rw-p 00000000 00:00 0 [stack:13762]
a5233000-a5236000 ---p 00000000 00:00 0
a5236000-a52b3000 rw-p 00000000 00:00 0 [stack:13761]
a52b3000-a52b4000 r--s 00001000 b3:02 131982 /home/pi/dsc-cassandra-1.2.5/lib/jamm-0.2.5.jar
a52b4000-a52c2000 r--s 000ad000 b3:02 131975 /home/pi/dsc-cassandra-1.2.5/lib/jackson-mapper-asl-1.9.2.jar
a52c2000-a52c6000 r--s 00034000 b3:02 131977 /home/pi/dsc-cassandra-1.2.5/lib/jackson-core-asl-1.9.2.jar
a52c6000-a52c9000 r--s 00015000 b3:02 131985 /home/pi/dsc-cassandra-1.2.5/lib/high-scale-lib-1.1.2.jar
a52c9000-a52ed000 r--s 001aa000 b3:02 131991 /home/pi/dsc-cassandra-1.2.5/lib/guava-13.0.1.jar
a52ed000-a52f0000 r--s 0000b000 b3:02 131979 /home/pi/dsc-cassandra-1.2.5/lib/concurrentlinkedhashmap-lru-1.3.jar
a52f0000-a52f2000 r--s 00005000 b3:02 131989 /home/pi/dsc-cassandra-1.2.5/lib/compress-lzf-0.8.4.jar
a52f2000-a52f7000 r--s 00041000 b3:02 131984 /home/pi/dsc-cassandra-1.2.5/lib/commons-lang-2.6.jar
a52f7000-a52f9000 r--s 00006000 b3:02 131931 /home/pi/dsc-cassandra-1.2.5/lib/commons-codec-1.2.jar
a52f9000-a52fa000 r--s 00008000 b3:02 131973 /home/pi/dsc-cassandra-1.2.5/lib/commons-cli-1.1.jar
a52fa000-a52ff000 r--s 0003f000 b3:02 131938 /home/pi/dsc-cassandra-1.2.5/lib/avro-1.4.0-sources-fixes.jar
a52ff000-a5309000 r--s 00088000 b3:02 131972 /home/pi/dsc-cassandra-1.2.5/lib/avro-1.4.0-fixes.jar
a5309000-a5315000 r--s 000fb000 b3:02 131939 /home/pi/dsc-cassandra-1.2.5/lib/apache-cassandra-thrift-1.2.5.jar
a5315000-a533f000 r--s 002b3000 b3:02 131993 /home/pi/dsc-cassandra-1.2.5/lib/apache-cassandra-1.2.5.jar
a533f000-a5354000 r--s 001c2000 b3:02 131932 /home/pi/dsc-cassandra-1.2.5/lib/antlr-3.2.jar
a5354000-a5357000 ---p 00000000 00:00 0
a5357000-a5381000 rw-p 00000000 00:00 0 [stack:13760]
a5381000-a5384000 ---p 00000000 00:00 0
a5384000-a53ae000 rw-p 00000000 00:00 0 [stack:13759]
a53ae000-a5525000 r--p 00000000 b3:02 16828 /usr/lib/locale/locale-archive
a5525000-a5528000 ---p 00000000 00:00 0
a5528000-a5552000 rw-p 00000000 00:00 0 [stack:13758]
a5552000-a5555000 ---p 00000000 00:00 0
a5555000-a557f000 rw-p 00000000 00:00 0 [stack:13757]
a557f000-a5580000 ---p 00000000 00:00 0
a5580000-a5670000 rw-p 00000000 00:00 0 [stack:13756]
a5670000-a5831000 r--s 03aab000 b3:02 131322 /usr/local/bin/java/jre/lib/rt.jar
a5831000-a588c000 rw-p 00000000 00:00 0
a588c000-a588d000 ---p 00000000 00:00 0
a588d000-a5eb0000 rw-p 00000000 00:00 0 [stack:13755]
a5eb0000-a5eb1000 rw-p 00000000 00:00 0
a5eb1000-a5f1f000 rw-p 00000000 00:00 0
a5f1f000-b3a20000 rw-p 00000000 00:00 0
b3a20000-b3b20000 rw-p 00000000 00:00 0
b3b20000-b3c0a000 rw-p 00000000 00:00 0
b3c0a000-b3d20000 rw-p 00000000 00:00 0
b3d20000-b3d22000 r--s 0001f000 b3:02 131988 /home/pi/dsc-cassandra-1.2.5/lib/servlet-api-2.5-20081211.jar
b3d22000-b3d24000 r--s 0001f000 b3:02 131981 /home/pi/dsc-cassandra-1.2.5/lib/lz4-1.1.0.jar
b3d24000-b3d2a000 r--s 00044000 b3:02 131940 /home/pi/dsc-cassandra-1.2.5/lib/libthrift-0.7.0.jar
b3d2a000-b3d39000 rw-p 00000000 00:00 0
b3d39000-b3db5000 rw-p 00000000 00:00 0
b3db5000-b3ead000 rwxp 00000000 00:00 0
b3ead000-b5db5000 rw-p 00000000 00:00 0
b5db5000-b6396000 rw-p 00000000 00:00 0
b6396000-b63b5000 rw-p 00000000 00:00 0
b63b5000-b63cd000 r-xp 00000000 b3:02 131240 /usr/local/bin/java/jre/lib/arm/libzip.so
b63cd000-b63d4000 ---p 00018000 b3:02 131240 /usr/local/bin/java/jre/lib/arm/libzip.so
b63d4000-b63d5000 rw-p 00017000 b3:02 131240 /usr/local/bin/java/jre/lib/arm/libzip.so
b63d5000-b63df000 r-xp 00000000 b3:02 4196 /lib/arm-linux-gnueabihf/libnss_files-2.13.so
b63df000-b63e6000 ---p 0000a000 b3:02 4196 /lib/arm-linux-gnueabihf/libnss_files-2.13.so
b63e6000-b63e7000 r--p 00009000 b3:02 4196 /lib/arm-linux-gnueabihf/libnss_files-2.13.so
b63e7000-b63e8000 rw-p 0000a000 b3:02 4196 /lib/arm-linux-gnueabihf/libnss_files-2.13.so
b63e8000-b63f1000 r-xp 00000000 b3:02 4216 /lib/arm-linux-gnueabihf/libnss_nis-2.13.so
b63f1000-b63f8000 ---p 00009000 b3:02 4216 /lib/arm-linux-gnueabihf/libnss_nis-2.13.so
b63f8000-b63f9000 r--p 00008000 b3:02 4216 /lib/arm-linux-gnueabihf/libnss_nis-2.13.so
b63f9000-b63fa000 rw-p 00009000 b3:02 4216 /lib/arm-linux-gnueabihf/libnss_nis-2.13.so
b63fa000-b640b000 r-xp 00000000 b3:02 4210 /lib/arm-linux-gnueabihf/libnsl-2.13.so
b640b000-b6412000 ---p 00011000 b3:02 4210 /lib/arm-linux-gnueabihf/libnsl-2.13.so
b6412000-b6413000 r--p 00010000 b3:02 4210 /lib/arm-linux-gnueabihf/libnsl-2.13.so
b6413000-b6414000 rw-p 00011000 b3:02 4210 /lib/arm-linux-gnueabihf/libnsl-2.13.so
b6414000-b6416000 rw-p 00000000 00:00 0
b6416000-b641c000 r-xp 00000000 b3:02 4212 /lib/arm-linux-gnueabihf/libnss_compat-2.13.so
b641c000-b6423000 ---p 00006000 b3:02 4212 /lib/arm-linux-gnueabihf/libnss_compat-2.13.so
b6423000-b6424000 r--p 00005000 b3:02 4212 /lib/arm-linux-gnueabihf/libnss_compat-2.13.so
b6424000-b6425000 rw-p 00006000 b3:02 4212 /lib/arm-linux-gnueabihf/libnss_compat-2.13.so
b6425000-b642e000 r-xp 00000000 b3:02 131205 /usr/local/bin/java/jre/lib/arm/libinstrument.so
b642e000-b6436000 ---p 00009000 b3:02 131205 /usr/local/bin/java/jre/lib/arm/libinstrument.so
b6436000-b6437000 rw-p 00009000 b3:02 131205 /usr/local/bin/java/jre/lib/arm/libinstrument.so
b6437000-b645a000 r-xp 00000000 b3:02 131211 /usr/local/bin/java/jre/lib/arm/libjava.so
b645a000-b6462000 ---p 00023000 b3:02 131211 /usr/local/bin/java/jre/lib/arm/libjava.so
b6462000-b6463000 rw-p 00023000 b3:02 131211 /usr/local/bin/java/jre/lib/arm/libjava.so
b6463000-b646e000 r-xp 00000000 b3:02 131239 /usr/local/bin/java/jre/lib/arm/libverify.so
b646e000-b6476000 ---p 0000b000 b3:02 131239 /usr/local/bin/java/jre/lib/arm/libverify.so
b6476000-b6477000 rw-p 0000b000 b3:02 131239 /usr/local/bin/java/jre/lib/arm/libverify.so
b6477000-b647d000 r-xp 00000000 b3:02 4191 /lib/arm-linux-gnueabihf/librt-2.13.so
b647d000-b6484000 ---p 00006000 b3:02 4191 /lib/arm-linux-gnueabihf/librt-2.13.so
b6484000-b6485000 r--p 00005000 b3:02 4191 /lib/arm-linux-gnueabihf/librt-2.13.so
b6485000-b6486000 rw-p 00006000 b3:02 4191 /lib/arm-linux-gnueabihf/librt-2.13.so
b6486000-b6489000 ---p 00000000 00:00 0
b6489000-b64b3000 rw-p 00000000 00:00 0 [stack:13754]
b64b3000-b651b000 r-xp 00000000 b3:02 4215 /lib/arm-linux-gnueabihf/libm-2.13.so
b651b000-b6522000 ---p 00068000 b3:02 4215 /lib/arm-linux-gnueabihf/libm-2.13.so
b6522000-b6523000 r--p 00067000 b3:02 4215 /lib/arm-linux-gnueabihf/libm-2.13.so
b6523000-b6524000 rw-p 00068000 b3:02 4215 /lib/arm-linux-gnueabihf/libm-2.13.so
b6524000-b69c1000 r-xp 00000000 b3:02 131191 /usr/local/bin/java/jre/lib/arm/client/libjvm.so
b69c1000-b69c9000 ---p 0049d000 b3:02 131191 /usr/local/bin/java/jre/lib/arm/client/libjvm.so
b69c9000-b69eb000 rw-p 0049d000 b3:02 131191 /usr/local/bin/java/jre/lib/arm/client/libjvm.so
b69eb000-b6e08000 rw-p 00000000 00:00 0
b6e08000-b6e28000 r-xp 00000000 b3:02 1234 /lib/arm-linux-gnueabihf/libgcc_s.so.1
b6e28000-b6e2f000 ---p 00020000 b3:02 1234 /lib/arm-linux-gnueabihf/libgcc_s.so.1
b6e2f000-b6e30000 rw-p 0001f000 b3:02 1234 /lib/arm-linux-gnueabihf/libgcc_s.so.1
b6e30000-b6f52000 r-xp 00000000 b3:02 4207 /lib/arm-linux-gnueabihf/libc-2.13.so
b6f52000-b6f59000 ---p 00122000 b3:02 4207 /lib/arm-linux-gnueabihf/libc-2.13.so
b6f59000-b6f5b000 r--p 00121000 b3:02 4207 /lib/arm-linux-gnueabihf/libc-2.13.so
b6f5b000-b6f5c000 rw-p 00123000 b3:02 4207 /lib/arm-linux-gnueabihf/libc-2.13.so
b6f5c000-b6f5f000 rw-p 00000000 00:00 0
b6f5f000-b6f61000 r-xp 00000000 b3:02 4213 /lib/arm-linux-gnueabihf/libdl-2.13.so
b6f61000-b6f68000 ---p 00002000 b3:02 4213 /lib/arm-linux-gnueabihf/libdl-2.13.so
b6f68000-b6f69000 r--p 00001000 b3:02 4213 /lib/arm-linux-gnueabihf/libdl-2.13.so
b6f69000-b6f6a000 rw-p 00002000 b3:02 4213 /lib/arm-linux-gnueabihf/libdl-2.13.so
b6f6a000-b6f7f000 r-xp 00000000 b3:02 131194 /usr/local/bin/java/jre/lib/arm/jli/libjli.so
b6f7f000-b6f86000 ---p 00015000 b3:02 131194 /usr/local/bin/java/jre/lib/arm/jli/libjli.so
b6f86000-b6f87000 rw-p 00014000 b3:02 131194 /usr/local/bin/java/jre/lib/arm/jli/libjli.so
b6f87000-b6f9b000 r-xp 00000000 b3:02 4199 /lib/arm-linux-gnueabihf/libpthread-2.13.so
b6f9b000-b6fa2000 ---p 00014000 b3:02 4199 /lib/arm-linux-gnueabihf/libpthread-2.13.so
b6fa2000-b6fa3000 r--p 00013000 b3:02 4199 /lib/arm-linux-gnueabihf/libpthread-2.13.so
b6fa3000-b6fa4000 rw-p 00014000 b3:02 4199 /lib/arm-linux-gnueabihf/libpthread-2.13.so
b6fa4000-b6fa7000 rw-p 00000000 00:00 0
b6fa7000-b6fa9000 r--s 00015000 b3:02 131987 /home/pi/dsc-cassandra-1.2.5/lib/jline-1.0.jar
b6fa9000-b6fb1000 rw-s 00000000 b3:02 134893 /tmp/hsperfdata_pi/13720
b6fb1000-b6fb3000 r-xp 00000000 b3:02 31794 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
b6fb3000-b6fba000 ---p 00002000 b3:02 31794 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
b6fba000-b6fbb000 rw-p 00001000 b3:02 31794 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
b6fbb000-b6fd8000 r-xp 00000000 b3:02 4200 /lib/arm-linux-gnueabihf/ld-2.13.so
b6fd8000-b6fd9000 r--s 00003000 b3:02 131937 /home/pi/dsc-cassandra-1.2.5/lib/json-simple-1.1.jar
b6fd9000-b6fda000 r--s 00004000 b3:02 131935 /home/pi/dsc-cassandra-1.2.5/lib/jbcrypt-0.3m.jar
b6fda000-b6fdb000 r--s 00008000 b3:02 131986 /home/pi/dsc-cassandra-1.2.5/lib/apache-cassandra-clientutil-1.2.5.jar
b6fdb000-b6fdc000 r--p 00000000 00:00 0
b6fdc000-b6fe0000 rw-p 00000000 00:00 0
b6fe0000-b6fe1000 r--p 0001d000 b3:02 4200 /lib/arm-linux-gnueabihf/ld-2.13.so
b6fe1000-b6fe2000 rw-p 0001e000 b3:02 4200 /lib/arm-linux-gnueabihf/ld-2.13.so
be7e4000-be805000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]

VM Arguments:
jvm_args: -ea -javaagent:bin/../lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms219M -Xmx219M -Xmn54M -XX:+HeapDumpOnOutOfMemoryError -Xss180k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseTLAB -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=7199 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes
java_command: org.apache.cassandra.service.CassandraDaemon
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/usr/local/bin/java
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/usr/local/bin/java/bin
SHELL=/bin/bash

Signal Handlers:
SIGSEGV: [libjvm.so+0x43dc98], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x43dc98], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x342238], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x342238], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x342238], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x342238], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x3424c8], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x3425c8], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x3425c8], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x3425c8], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x3425c8], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004

--------------- S Y S T E M ---------------

OS:7.0

uname:Linux 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l
libc:glibc 2.13 NPTL 2.13
rlimit: STACK 8192k, CORE 0k, NPROC 3377, NOFILE 4096, AS infinity
load average:0.16 0.11 0.14

/proc/meminfo:
MemTotal: 448776 kB
MemFree: 52400 kB
Buffers: 21636 kB
Cached: 284668 kB
SwapCached: 0 kB
Active: 204568 kB
Inactive: 165036 kB
Active(anon): 50388 kB
Inactive(anon): 13160 kB
Active(file): 154180 kB
Inactive(file): 151876 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 102396 kB
SwapFree: 102396 kB
Dirty: 1324 kB
Writeback: 0 kB
AnonPages: 63368 kB
Mapped: 12796 kB
Shmem: 220 kB
Slab: 18892 kB
SReclaimable: 15376 kB
SUnreclaim: 3516 kB
KernelStack: 1192 kB
PageTables: 844 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 326784 kB
Committed_AS: 341540 kB
VmallocTotal: 565248 kB
VmallocUsed: 756 kB
VmallocChunk: 350692 kB

CPU:total 1 (ARMv6), vfp

/proc/cpuinfo:
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 000e
Serial : 00000000a61bd1f9

Memory: 4k page, physical 448776k(52400k free), swap 102396k(102396k free)

vm_info: Java HotSpot(TM) Client VM (25.0-b04) for linux-arm-vfp JRE (1.8.0-ea-b36e), built on Nov 29 2012 23:45:48 by "java_re" with gcc 4.7.2 20120910 (prerelease)

time: Sun Jun 23 22:04:28 2013
elapsed time: 13 seconds

optimize snappy framed outputstream for NIO

The Snappy class has an api which allows compression (and decompression) using Direct ByteBuffers. When I originally developed the SnappyFramedOutputStream, I did not use those apis, since calculating the crc32 must be done on the heap (not in native memory). I was not considering the advantages of using the Direct ByteBuffer if the "target" stream (or channel) were optimized for NIO (such as a FileChannel).

I am working on a change now that will "buffer" frames in heap (since CRC32 must be calculated off heap), then copy to Direct for compression and use the Direct ByteBuffer to write compressed frame to "target" channel.

Solaris x86_64 native library are missing

Hello,

I have the same problem than one related in issue #42 when running a jvm with -d64 flag on a solaris x86 host.

Native library for architecture reported as amd64 are not present in the snappy distribution. I tried to add this architecture .so files after compiling snappy
in 64 bits mode but encounter another error that I wasn't able to solve at this time.

[P]zen:/tmp# java -d64 -cp ".:./snappy-java-1.0.5-patch-amd64.jar" Main
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.maxCompressedLength(I)I
at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method)
at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:320)
at org.xerial.snappy.Snappy.rawCompress(Snappy.java:333)
at org.xerial.snappy.Snappy.compress(Snappy.java:92)
at Main.main(Main.java:10)

Add isValidCompressedData API for raw memory address

temp files not deleted

The temporary file being created for the native library loading is not being deleted at shutdown.
This might be because the deleteOnExit() method is being called on a File which does not yet exist.
In SnappyLoader.extractLibraryFile, The random name is generated, and a File in the temp directory is instantiated, but not created.

        String extractedLibFileName = String.format("snappy-%s-%s-%s", getVersion(), uuid, libraryFileName);
        File extractedLibFile = new File(targetFolder, extractedLibFileName);
        // Delete extracted lib file on exit.
        extractedLibFile.deleteOnExit();

        try {
            // Extract a native library file into the target directory
            InputStream reader = SnappyLoader.class.getResourceAsStream(nativeLibraryFilePath);
            FileOutputStream writer = new FileOutputStream(extractedLibFile);

The file itself does not get created until the FileOutputStream is created.

ready() is not implemented in SnappyInputStream and SnappyOutputStream

Please describe a summary of the new feature (in a paragraph):

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=41

[FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=x86

Hi
I am using snappy version snappy-java-1.1.0-M3. On windows system its working fine. But when deployed to Linux system I got the error

Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=x86
at org.xerial.snappy.SnappyLoader.findNativeLibrary(SnappyLoader.java:460)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:318)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.(Snappy.java:48)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)

It appears like it needs the system library in folder linux/x86 which is not present.

snappy-java is not compatible with Felix 4.0.3

Snappy-java 1.1.0M4 does not start properly in Felix 4.0.3.

This appears to be a re-occurence of #36
It appears to be the selection filter vs mandatory parameter issue.

From what I can see it was fixed on June 06 by this commit: cfebd74#diff-600376dffeb79835ede4a0b285078036

Then something was merged on August 13 that caused both mandatory and selection filter to be present: dc20eaf#diff-600376dffeb79835ede4a0b285078036

And on the same day the mandatory parameters disappeared and were replaced by selection filter again: 640f626#diff-600376dffeb79835ede4a0b285078036

I've also noticed that its been alternating from x86_64 to x86-64 and back. x86-64 is correct according to http://www.osgi.org/Specifications/Reference#processor

snappy-java-1.1.0 release

• Upgrade to snappy-1.1.0 for slight performance improvement
• New native code loader
• Deploy to maven central

[FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=x86

Hi Guys,
It looks like I ran into an issue with running this on 32-Bit IBM JDK under WebSphere 7.0 with 64-bit CPU. Things work fine with 64-Bit Open JDK on same linux server. Unfortunately I have to run this under WebSphere and re-compiling JDK isn't an option at the moment.

Would you be able to help?

Initial Error under 32 bit JDK:
[FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=x86

I tried to copy amd64 under Linux folder to x86 and that's when I realized 64 vs. 32 bit issue.

-bash-4.1$ /opt/IBM/WebSphere/AppServer/java/bin/java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxi3260sr12-20121025_01(SR12))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT - r9_20120914_26057
GC - 20120928_AA)
JCL - 20121014_01
-bash-4.1$ /opt/IBM/WebSphere/AppServer/java/bin/java -cp snappy-java-1.0.5.jar org.xerial.snappy.OSInfo
Linux/x86-bash-4.1$
-bash-4.1$
-bash-4.1$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.5) (rhel-1.50.1.11.5.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
-bash-4.1$ java -cp snappy-java-1.0.5.jar org.xerial.snappy.OSInfo
Linux/amd64-bash-4.1$
-bash-4.1$
-bash-4.1$ /opt/IBM/WebSphere/AppServer/java/bin/java -cp snappy-java-1.0.5.jar:. SnappyTest
null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:322)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.(Snappy.java:48)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at SnappyTest.main(SnappyTest.java:8)
Caused by: java.lang.UnsatisfiedLinkError: /tmp/snappy-1.0.5-libsnappyjava.so (/tmp/snappy-1.0.5-libsnappyjava.so: wrong ELF class: ELFCLASS64)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1018)
at java.lang.System.load(System.java:494)
at org.xerial.snappy.SnappyNativeLoader.load(SnappyNativeLoader.java:39)
... 10 more
org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:239)
at org.xerial.snappy.Snappy.(Snappy.java:48)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at SnappyTest.main(SnappyTest.java:8)
-bash-4.1$
-bash-4.1$
-bash-4.1$ java -cp snappy-java-1.0.5.jar:. SnappyTest

Dmitriy

Snappy cannot be used with OSGi 4.2.0

The version range of the org.osgi.framework package is [1.6,2), which means that is only installable on containers running the version 4.3.0 of the OSGi specification and prevents its installation in older versions of container (since 4.3.0 is brand new it excludes almost all containers).

Unless snappy uses explicit features of 4.3.0 version of the specification, it should have a wider version range.

I can see two approaches:
i) Downgrade the version of osgi version to 4.2.0.
ii) Set an explicitly the version range in the maven bundle plugin. Something like:
<instructions>
...
<Import-Package>org.osgi.framework;version="[1.5,2)"</Import-Package>
...
</instructions>

If you prefer a patch submission for this, I could provide one, but is a really minimal change (single line).

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=38

---

earlier comments

taroleo said, at 2012-01-18T07:01:15.000Z:

Thanks for the suggestion. I will fix this

iocanel said, at 2012-01-18T10:26:22.000Z:

Unfortunately, there are a lot more required in order to have snappy-java run inside OSGi. So far I haven't been able to find a solution that will run both OSGi and non-OSGi environments.

Ioannis Canellos
FuseSource

Blog: http://iocanel.blogspot.com
Apache Karaf Committer & PMC
Apache Camel Committer
Apache ServiceMix Committer
Apache Gora Committer
Apache DirectMemory Committer

taroleo said, at 2012-01-19T04:02:11.000Z:

Hi,

I guess the problem is loading JNI code inside OSGi. Snappy-java uses its own strategy to find dll files, while OSGi uses another specification to locate dll files.

Is it possible to configure the dll file locations at runtime? For example,
if OSGi allows setting the dll file location at the activation time, I can write a code to set the path to dll in SnappyBundleActivator class.

[email protected] said, at 2012-01-19T04:03:08.000Z:

This issue was updated by revision e9f8f2b6f001.

Set the osgi version range org.osgi.framework;version="[1.5,2)

iocanel said, at 2012-01-19T04:16:20.000Z:

Hi,

The problem is that snappy-java uses classloader in a manner not very OSGi friendly in an attempt to make classes available to the parent classloader. In OSGi this is not required and its also not working that well.
If you isolate that mechanim then things work well in OSGi.

I tried to create a shaded jar of snappy-java, that has a modified versions Snappy.java and SnappyLoader.java that are intended to run inside OSGi.
Here it is: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/snappy-java-1.0.4.1/

I don't know how easy it is to merge the two approaches so that we can have one artifact that run for both cases, so this is why I considered a shaded bundle a good approach. What do you think?

Ioannis Canellos
FuseSource

Blog: http://iocanel.blogspot.com
Apache Karaf Committer & PMC
Apache Camel Committer
Apache ServiceMix Committer
Apache Gora Committer
Apache DirectMemory Committer

taroleo said, at 2012-01-19T05:01:54.000Z:

Great.

If the class loading mechanism in OSGi starts with
SnappyBundleActivator.start, then initializes Snappy.class, it would be possible to merge two approaches.

Non-OSGi user: init Snappy -> SnappyLoader (load JNI files)
OSGi user: SnappyBundleActivator -> disable SnappyLoader -> init Snappy (no native lib injection to parent class loader. Simply do loadLibrary as your code)

If there is a chance that Snappy.class happens to be initialized before the bundle activation, two packages are needed for OSGi and non-OSGi users.

robert.stupp said, at 2012-05-31T21:51:08.000Z:

Hi,

I just received a similar problem with Snappy 1.0.4.1 when used in JBoss AS 7.1.1.

The snappy classes created by SnappyLoader are defined in the root class loader. But JBoss AS7's module class loader defines the same classes - so there are multiple classes and the application's snappy.jar cannot use the native code (UnsatisfiedLinkError) due to class loader "conflicts".

Regarding AS7 it is sufficient just to use the current class loader - just to let it work (hot re-deployment or use of snappy in multiple containers does not work with that approach).

For a quick fix it would be nice to have a Java system property that does something like this in SnappyLoader:

private static Class< ? > injectSnappyNativeLoader() {

    try {
        // Use parent class loader to load SnappyNative, since Tomcat, which uses different class loaders for each webapps, cannot load JNI interface twice

        final String nativeLoaderClassName = "org.xerial.snappy.SnappyNativeLoader";
        boolean useRootClassLoader = Boolean
            .parseBoolean(System.getProperty(KEY_SNAPPY_USE_ROOT_CLASS_LOADER, "true"));
        ClassLoader rootClassLoader = useRootClassLoader ? getRootClassLoader() : Thread.currentThread().getContextClassLoader();

...

taroleo said, at 2012-06-30T12:12:01.000Z:

Thanks for the report.

Does JBoss AS handle the UnsatisfiedLinkError problem when loading the same library twice in different class loaders?

Tomcat 7 still has this problem. So I am not sure which behavior (using root class loader or not) should be the default.

Test which class loader is available for the common use

Forked from issue #5

A simple test would be useful that injects a code to the parent class
loader then checks the injected code is visible from the current class
loader. If the injected code is not visible, switch the behavior of the
native code loading mechanism in snappy-java.

LoadNativeLibrary doesn't handle java.lang.reflect.InvocationTargetException

Remove the native libraries from the Snappy.jar file (to simulate not being able to load the native libraries for some reason)
Compile and run the attached test program.

What is the expected output? What do you see instead?
Expected the test code to catch the exception, instead java snappy throws:
java.lang.reflect.InvocationTargetException

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)
at org.xerial.snappy.Snappy.<clinit>(Snappy.java:44)
at testSnappy.<init>(testSnappy.java:12)
at testSnappy.main(testSnappy.java:6)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1758)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
... 9 more
Exception in thread "main" 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 testSnappy.<init>(testSnappy.java:12)
at testSnappy.main(testSnappy.java:6)

What version of the product are you using? On what operating system?
snappy-java-1.0.4.1 Debian Squeeze for Raspberry Pi

Please provide any additional information below.
I'm fairly sure this is thrown by loadMethod.invoke(null, "snappyjava"); in loadNativeLibrary (SnappyLoader.java) around line 317

The fault manifested itself tracking issue 4400 in the apache cassandra project

https://issues.apache.org/jira/browse/CASSANDRA-4400?focusedCommentId=13406480#comment-13406480

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=46

---

earlier comments

kimchy said, at 2012-07-22T20:30:26.000Z:

It would be great if the print to System.err will be removed in the next version, and let the calling code to handle it.

bradford.powell said, at 2012-08-15T18:20:53.000Z:

Comment 1 points at a use case that calling code may want to be informed of problems with initialization and respond (which may be by not using snappy, using an alternative method, logging/informing the user...). Specifically, an example is the picard project (picard.sourceforge.net) where snappy-java is used (via reflection) if available. If not, then the fallback is to not use compression.

In order to determine at first use of their snappy wrapper (net.sf.samtools.util.SnappyLoader) whether the library is available and can be loaded, thy had used LoadSnappy.load() (which is no longer available in 1.0.4, and the similar method in org.xerial.snappy.SnappyLoader is not public).

Initialization of org.xerial.snappy.Snappy could occur at a defined time using reflection by calling Class.forName("org.xerial.snappy.Snappy"), but any exceptions generated are swallowed because loading of the native library occurs in the Snappy static initializer (and static blocks cannot throw checked exceptions).

I see two potential ways to address this use case:

1. Allow some public static method to ensure that the native library is loaded (and throw and exception if loading is unsuccessful).
2. Throw an ExceptionInInitializerError if an Exception occurs in the static block of org.xerial.snappy.Snappy. This would allow the Error to be caught and handled if Class.forName is used, but I'm not sure that the effect for programs using the library without reflection would be ideal.

I attached a patch for option #2. Are there other ideas/singleton tricks that could be used?

1.1.1-M1 CompressFragment assertion failure

Using 1.1.1-M1, SnappyOutputStream to write, SnappyInputStream to read, I'm seeing sporadic

java: target/snappy-1.1.1/snappy.cc:423: char* snappy::internal::CompressFragment(const char*, size_t, char*, snappy::uint16*, int): Assertion `0 == memcmp(base, candidate, matched)' failed.

streaming documentation

The usage documentation on the main page references the proprietary SnappyOutputStream/SnappyInputStream for streaming usage. Should this be changed to recommend the use of SnappyFramedOutputStream/SnappyFramedInputStream as those provide a standard format?

Native library loading fails on openjdk7u4 for mac

What steps will reproduce the problem?

1. Install openjdk7u4 preview for mac
2. Invoke Snappy#compress

What is the expected output? What do you see instead?
I expect Snappy to work. But it fails to find the native library.

What version of the product are you using? On what operating system?
Snappy 1.0.4.1, OS X 10.7, OpenJDK7u4

Please provide any additional information below.
The openjdk guys have changed System.mapLibraryName to return an extension of "dylib" instead of "jnilib". It looks like this will be the standard for openjdk7 on mac. They have put some backwards compatibility hooks in System.loadLibrary, but this does not help the code in SnappyLoader.

The related code is in SnappyLoader:

    // Resolve the library file name with a suffix (e.g., dll, .so, etc.) 
    if (snappyNativeLibraryName == null)
        snappyNativeLibraryName = System.mapLibraryName("snappyjava");

    if (snappyNativeLibraryPath != null) {
        File nativeLib = new File(snappyNativeLibraryPath, snappyNativeLibraryName);
        if (nativeLib.exists())
            return nativeLib;
    }

    {
        // Load an OS-dependent native library inside a jar file
        snappyNativeLibraryPath = "/org/xerial/snappy/native/" + OSInfo.getNativeLibFolderPathForCurrentOS();

        if (SnappyLoader.class.getResource(snappyNativeLibraryPath + "/" + snappyNativeLibraryName) != null) {

On OpenJDK7 on Mac, it attempts to look for libsnappyjava.dylib. In the jar, it is packaged as libsnappyjava.jnilib, so it fails.

It seems the only reasonable fix is to check for both the dylib and jnilib extensions when on a Mac.

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=39

---

earlier comments

[email protected] said, at 2012-06-26T04:06:14.000Z:

Duplicating "libsnappyjava.jnilib" with a .dylib extension fixed the issue for me too.

taroleo said, at 2012-06-30T12:04:12.000Z:

Issue 42 has been merged into this issue.

taroleo said, at 2012-06-30T12:04:26.000Z:

Issue 42 has been merged into this issue.

Add rawCompress/Uncompress for memory addresses

LArray https://github.com/xerial/larray uses off-heap memory. Extend snappy-java to enable zero-copy compression/decompression on LArray.

Add armhf native library

Please describe a summary of the new feature (in a paragraph):

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=44

SnappyFramedInputStream throws invalid EOF

In the constructor of the snappy framed input stream, it throws an exception if the read from underlying source does not return all of the header bytes in a single read call. There is even a comment about assuming there is a problem if all of the bytes cannot be read in single call. This is a bad assumption. It should read until needed bytes are read or EOF is explicitly reached.

jee clean up

Please either provide a http://docs.oracle.com/javaee/5/api/javax/servlet/ServletContextListener.html that calls Snappy.cleanUp as part of the contextDestroyed method, or make Snappy.cleanUp public so that others can provide similar functionality in their code.

Add an option to build snappy-java that uses pre-installed Snappy

Please describe a summary of the new feature (in a paragraph):

Some Linux distribution already contains snappy library, which might be applied some system-specific pathces. To use snappy-java in such a system, splitting libsnappyjava.so (containing C++ code to access Snappy and the original Snappy's code) would be desirable to allow snappy-java to use system installed Snappy.

In addition, some user might want a light-weight library which only contains dll's for a target system. The current snappy-java contains many binaries for Win/Mac/Linux with 32/64-bit CPUs.

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=36

If Snappy-Java supports Thread-Safe?

  Recently I use Snappy-java for compressing bytes[] in Java. It's a multi-thread environment, I see your implementation is based on this code:
         int compressedByteSize = ((SnappyNativeAPI) impl).rawCompress(data, 0, byteSize, buf, 0);
  "impl" is a JNI implementation, I wonder that if it supports Thread-Safe or do you deal concurrent problem in JNI?
  Thanks.

Snappy does not work under Tomcat 8.0.0-RC10

Works fine under Tomcat 8.0.0-RC5. I am not sure what the differences are between these two versions.

Snappy version is 1.0.5, exception is

Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/127.0.0.1 ([localhost/127.0.0.1] Unexpected error during transport initialization (com.datastax.driver.core.TransportException: [localhost/127.0.0.1] Unexpected exception triggered (java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.isValidCompressedBuffer(Ljava/lang/Object;II)Z))))

Improve the performance by reusing buffers

Please describe a summary of the new feature (in a paragraph):

Some compressor implementations use BufferRecycler to improve the performance count in jvm-compressor-benchmark. For example, following BufferRecycle can be used to avoid allocating buffers for every Snappy API calls.
https://github.com/ning/compress/blob/master/src/main/java/com/ning/compress/lzf/BufferRecycler.java

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=35

Create an index to allow parallel compression and decompression

Please describe a summary of the new feature (in a paragraph):

SnappyOutputStream creates a sequence of chunks (compressed byte size, compressed data[uncompressed length, compressed binary])..., so pointers to each chunk can be used for parallel decompression.
And also block-wise compression is likely possible by blocking input data set and concatenating compressed chunks to create the same output as in SnapppyOutputStream.

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=15

provide optimized transfer methods

It is a common use case when interacting with the SnappyFramedInputStream or SnappyFramedOutputStream to want to transfer from/to another stream. This is typically accomplished by creating a buffer and reading/writing from input stream to output stream. Since the SnappyFramed streams are already backed by buffers, the intermediary buffering could be skipped, (potentially) resulting in better performance.

SnappyNative.h generation failed

What steps will reproduce the problem?

1. touch src/main/java/org/xerial/snappy/SnappyNative.java
2. do make clean clean-native native
3. failed when running javah

Compilation of SnappyNative.java must be ahead of javah.

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=43

Makefile for building native libraries using Ubuntu

Please describe a summary of the new feature (in a paragraph):

Please provide any additional information below:

Migrated from http://code.google.com/p/snappy-java/issues/detail?id=45

aggressively reclaim direct byte buffers

Under heavy usage, the direct byte buffers may not free up native memory, leading to
Caused by: java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:658)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306)
at org.xerial.snappy.SnappyFramedOutputStream.(SnappyFramedOutputStream.java:149)

Even on a system 50+GB of memory available.
Sun has proprietary methods on a direct byte buffer to allow forcible cleaning.

What happened to libstdc++ statically linked builds?

Snappy won't work on some systems with following (and similar) configuration(s):

CentOS 5.5 (x86_64):
libstdc++-4.1.2-52.el5_8.1
glibc-2.5-81.el5_8.7

Previously, it was resolved here: http://code.google.com/p/snappy-java/issues/detail?id=12
by doing a build with statically libstdc++ linked and included snappy version.

And some of the older builds actually do work there, for example:
http://maven.xerial.org/repository/snapshot/org/xerial/snappy/snappy-java/1.0.1-rc5-SNAPSHOT/ .

Snappy.compress declares to throw IOException but does not throw any.

Snappy.compress method declaration includes "throws IOException". Implementation just calls rawCompress() that does not throw IOException so this throws is not needed.

It makes sense that when operating on in memory byte array there is no place to throw IOException.

SnappyLoader takes minutes to initialize

Sometimes SnappyLoader takes several minutes to initialize (in my case it happens when connecting via a remote debugger to a process which uses snappy via some transitive dependency).

Specifically, it's SnappyLoader.md5sum() that takes ages to complete. I suspect the problem might be with calling digestInputStream.read(), i.e. reading the stream and updating the digest one byte at a time - it is far more efficient to be working with a buffer (even a small 4K buffer will do) and reading it in one fell swoop.

Or, at a higher level, there's actually no reason to use an md5 digest to compare two streams - it would be more efficient and straightforward to just compare the content of the streams directly for equality, with no digest or other calculations (but here too it should be done using a buffer, not reading them byte by byte and comparing). There are plenty of such stream equality utility methods to be found, so no need to write it from scratch either.

two question

1:

Snappy.compress/ Snappy.uncompress 

related methods is thread safe?

2:
if want to use

compress(byte[] input, int inputOffset, int inputLength, byte[] output, int outputOffset)

method reduce the memory copy,how to defined output array legth.

I can't get any email list ,so ask here

Please return 32bit version of Snappy to Mac as it is possible to run Java 6 in 32 bit VM configuration

We got following exception in the - Unable to load Snappy library (OS: Mac OS X 10.8.3)
org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=i386
E.g. Open java application package information (e.g. IntelliJ IDEA CE), set "use 32 bit" option : http://stackoverflow.com/a/7050886

Relevant commit
a5dcbb7

add support for x-snappy-framed format

Google has defined a framing format named x-snappy-framed. It is not compatible with the existing SnappyInputStream/SnappyOutputStream in this project.

http://snappy.googlecode.com/svn/trunk/framing_format.txt