[
https://issues.apache.org/jira/browse/HADOOP-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949178#comment-14949178
]
Colin Patrick McCabe commented on HADOOP-11127:
-----------------------------------------------
Hi [~alanburlison],
Thanks for posting your proposal in proposal.txt. Let me take a look:
I don't view option #3 (Bundle the JNI component inside the JAR alongside the
Java component and distribute that as part of the jobs) as unworkable. If the
cluster contains multiple different platforms, we can have code that selects
the correct one. I also feel that this use case is extremely, extremely rare
(to the point where I've never actually seen it, and I doubt anyone here has
either). We could certainly have an escape valve just for this case where we
look for a system {{libhadoop.so}}. However, this is something we could
consider later.
Versioning: I agree that internal versioning is overly complex for what we
need. As you mention, the version suffixes on libraries are not supported by
{{java.lang.System.loadLibrary}}, so we can't use that. I think the proposal
for forming a composite name is very reasonable.
+1 for the proposal in proposal.txt.
> Improve versioning and compatibility support in native library for downstream
> hadoop-common users.
> --------------------------------------------------------------------------------------------------
>
> Key: HADOOP-11127
> URL: https://issues.apache.org/jira/browse/HADOOP-11127
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
> Reporter: Chris Nauroth
> Assignee: Alan Burlison
> Attachments: HADOOP-11064.003.patch, proposal.txt
>
>
> There is no compatibility policy enforced on the JNI function signatures
> implemented in the native library. This library typically is deployed to all
> nodes in a cluster, built from a specific source code version. However,
> downstream applications that want to run in that cluster might choose to
> bundle a hadoop-common jar at a different version. Since there is no
> compatibility policy, this can cause link errors at runtime when the native
> function signatures expected by hadoop-common.jar do not exist in
> libhadoop.so/hadoop.dll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
