[
https://issues.apache.org/jira/browse/HADOOP-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HADOOP-8756:
-----------------------------------------
Target Version/s: 2.2.0-alpha
Affects Version/s: 2.2.0-alpha
> libsnappy loader issues
> -----------------------
>
> Key: HADOOP-8756
> URL: https://issues.apache.org/jira/browse/HADOOP-8756
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
> Affects Versions: 2.2.0-alpha
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Priority: Minor
>
> * We use {{System.loadLibrary("snappy")}} from the Java side. However in
> libhadoop, we use {{dlopen}} to open libsnappy.so dynamically. It seems like
> the System.loadLibrary nonsense is completely redundant-- we would only need
> this if we planned on accessing libsnappy methods directly from Java (via the
> 'native' keyword)- - which we don't, and can't, since snappy is not JNI. At
> the end of the day, snappy is only accessible through libhadoop.so, so I
> think snappy-related issues should be handled there.
> * We should log the search path(s) we use for {{libsnappy.so}}, so that it's
> easier to diagnose configuration issues.
> * It seems like the static initialization code in the LoadSnappy.java class
> references the static initialization code in NativeCodeLoader. Basically, if
> the init method in NativeCodeLoader doesn't run before the init method in
> LoadSnappy, there could be problems. We should avoid having this kind of
> issue.
--
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
