Cassandra
  1. Cassandra
  2. CASSANDRA-4400

Correctly catch exception when Snappy cannot be loaded

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: 1.1.3
    • Component/s: None
    • Labels:
      None

      Description

      From the mailing list, on C* 1.1.1:

      INFO 14:22:07,600 Global memtable threshold is enabled at 35MB
      java.lang.reflect.InvocationTargetException
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:616)
              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 org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
              at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)
              at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37)
              at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:76)
              at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
              at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
              at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:118)
              at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
              at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
              at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
      Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
              at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
              at java.lang.Runtime.loadLibrary0(Runtime.java:840)
              at java.lang.System.loadLibrary(System.java:1047)
              at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
              ... 17 more
      ERROR 14:22:09,934 Exception encountered during startup
      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 org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
              at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)
              at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37)
              at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:76)
              at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
              at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
              at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:118)
              at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
              at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
              at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
      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 org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
              at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)
              at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37)
              at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:76)
              at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
              at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
              at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:118)
              at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
              at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
              at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
      Exception encountered during startup: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
      
      1. 4400.txt
        1 kB
        Sylvain Lebresne

        Activity

        Hide
        Sylvain Lebresne added a comment -

        Is there a reason Cassandra's not using the pure Java version of Snappy?

        An very quick look at those benchmarks seems to suggest that the JNI impl is still faster on read, which is what we mainly care about. That being said, it wouldn't be crazy to fallback to the pure Java version if the JNI one can't be loaded, provided this is not too complicated to do. At least patches are welcome

        Show
        Sylvain Lebresne added a comment - Is there a reason Cassandra's not using the pure Java version of Snappy? An very quick look at those benchmarks seems to suggest that the JNI impl is still faster on read, which is what we mainly care about. That being said, it wouldn't be crazy to fallback to the pure Java version if the JNI one can't be loaded, provided this is not too complicated to do. At least patches are welcome
        Hide
        Drew Kutcharian added a comment -

        Is there a reason Cassandra's not using the pure Java version of Snappy? https://github.com/dain/snappy
        The performance numbers are very similar. https://github.com/ning/jvm-compressor-benchmark/wiki

        Show
        Drew Kutcharian added a comment - Is there a reason Cassandra's not using the pure Java version of Snappy? https://github.com/dain/snappy The performance numbers are very similar. https://github.com/ning/jvm-compressor-benchmark/wiki
        Hide
        Yuki Morishita added a comment -
        Show
        Yuki Morishita added a comment - Oleg Mygryn I think you are seeing this https://github.com/xerial/snappy-java/issues/6 .
        Hide
        Sylvain Lebresne added a comment -

        As said above, this is logged by SnappyJava itself so there is nothing we can do about that. But this is only cosmetic, you should disregard the trace itself (it does indicate that you won't have compression enable but that's a totally different problem).

        Show
        Sylvain Lebresne added a comment - As said above, this is logged by SnappyJava itself so there is nothing we can do about that. But this is only cosmetic, you should disregard the trace itself (it does indicate that you won't have compression enable but that's a totally different problem).
        Hide
        Oleg Mygryn added a comment - - edited

        Hey Guys,
        Was it fixed in 1.1.6 ?
        See the same trace:

        Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
        at java.lang.Runtime.loadLibrary0(Runtime.java:845)
        at java.lang.System.loadLibrary(System.java:1084)
        at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
        ... 17 more

        Cassandra-1.1.6
        OSX 10.8 JDK "1.7.0_07"
        Any Ideas ?

        Show
        Oleg Mygryn added a comment - - edited Hey Guys, Was it fixed in 1.1.6 ? See the same trace: Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:845) at java.lang.System.loadLibrary(System.java:1084) at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52) ... 17 more Cassandra-1.1.6 OSX 10.8 JDK "1.7.0_07" Any Ideas ?
        Hide
        Sylvain Lebresne added a comment -

        As explain above, the large stack trace is thrown by the Snappy library itself, so until they fix that there is nothing we can do about it, sorry.

        Show
        Sylvain Lebresne added a comment - As explain above, the large stack trace is thrown by the Snappy library itself, so until they fix that there is nothing we can do about it, sorry.
        Hide
        Archimedes Trajano added a comment -

        Although it catches it properly, it still throws a large stack trace. Is it possible to get rid of it?

        Show
        Archimedes Trajano added a comment - Although it catches it properly, it still throws a large stack trace. Is it possible to get rid of it?
        Hide
        Sylvain Lebresne added a comment -

        Alright, committed, thanks

        Show
        Sylvain Lebresne added a comment - Alright, committed, thanks
        Hide
        Andy Cobley added a comment -

        Yep Sylvian, I've tested it and am happy.

        Show
        Andy Cobley added a comment - Yep Sylvian, I've tested it and am happy.
        Hide
        Sylvain Lebresne added a comment -

        Yeah so there is not much more we can do in the meantime. @Andy you tested the attached patch succesfully, right? If so I'll commit that.

        Show
        Sylvain Lebresne added a comment - Yeah so there is not much more we can do in the meantime. @Andy you tested the attached patch succesfully, right? If so I'll commit that.
        Hide
        Andy Cobley added a comment -

        Sylvian,
        I've done a little digging into the snappy source code, looks like they are not catching a java.lang.reflect.InvocationTargetException at line 319 of SnappyLoader:

        loadMethod.invoke(null, nativeLib.getAbsolutePath());

        I'll try and raise a ticket with them.

        Are you happy to commit your changes for 1.1.3?

        Show
        Andy Cobley added a comment - Sylvian, I've done a little digging into the snappy source code, looks like they are not catching a java.lang.reflect.InvocationTargetException at line 319 of SnappyLoader: loadMethod.invoke(null, nativeLib.getAbsolutePath()); I'll try and raise a ticket with them. Are you happy to commit your changes for 1.1.3?
        Hide
        Andy Cobley added a comment -

        let me confirm thats the problem if thats the case, yes a ticket should be opened.

        Show
        Andy Cobley added a comment - let me confirm thats the problem if thats the case, yes a ticket should be opened.
        Hide
        Sylvain Lebresne added a comment -

        So I guess the current output is the best we can do and we can open a ticket on Snappy-Java to have them remove that.

        Show
        Sylvain Lebresne added a comment - So I guess the current output is the best we can do and we can open a ticket on Snappy-Java to have them remove that.
        Hide
        Andy Cobley added a comment -

        I think it's being printed by :

        static {
        try

        { impl = SnappyLoader.load(); }

        catch (Exception e)

        { e.printStackTrace(); }

        in Snappy.java line 47. I can experiment and confirm

        Show
        Andy Cobley added a comment - I think it's being printed by : static { try { impl = SnappyLoader.load(); } catch (Exception e) { e.printStackTrace(); } in Snappy.java line 47. I can experiment and confirm
        Hide
        Sylvain Lebresne added a comment -

        Actually, I'd like to get rid of that exception at startup but I'm not sure why that InvocationTargetException is not caught by the 'catch (Exception e)' in SnappyCompressor.isAvailable(). Unless it's printed in the log by the snappy library itself.

        Show
        Sylvain Lebresne added a comment - Actually, I'd like to get rid of that exception at startup but I'm not sure why that InvocationTargetException is not caught by the 'catch (Exception e)' in SnappyCompressor.isAvailable(). Unless it's printed in the log by the snappy library itself.
        Hide
        Andy Cobley added a comment -

        I added your fix to the source of apache-cassandra-1.1.1-src and it does allow a startup if SnappyJava is missing. The only thing I not is the log from the startup is a bit messy with exceptions thrown, but I'm guessing this acceptable ?

        INFO 15:42:57,873 Global memtable threshold is enabled at 35MB
        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 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.<clinit>(SnappyCompressor.java:38)
        at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:76)
        at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
        at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
        at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:118)
        at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
        at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
        at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
        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
        WARN 15:42:59,586 Cannot initialize native Snappy library. Compression on new tables will be disabled.
        INFO 15:43:00,141 Initializing key cache with capacity of 5 MBs.

        Show
        Andy Cobley added a comment - I added your fix to the source of apache-cassandra-1.1.1-src and it does allow a startup if SnappyJava is missing. The only thing I not is the log from the startup is a bit messy with exceptions thrown, but I'm guessing this acceptable ? INFO 15:42:57,873 Global memtable threshold is enabled at 35MB 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 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.<clinit>(SnappyCompressor.java:38) at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:76) at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79) at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439) at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:118) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) 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 WARN 15:42:59,586 Cannot initialize native Snappy library. Compression on new tables will be disabled. INFO 15:43:00,141 Initializing key cache with capacity of 5 MBs.
        Hide
        Sylvain Lebresne added a comment -

        Patch attached to be a little bit more thorough in which errors we catch.

        Show
        Sylvain Lebresne added a comment - Patch attached to be a little bit more thorough in which errors we catch.

          People

          • Assignee:
            Sylvain Lebresne
            Reporter:
            Sylvain Lebresne
            Reviewer:
            Andy Cobley
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development