[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146970#comment-14146970
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12671048/HADOOP-11064.006.patch
against trunk revision 9fa5a89.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-common-project/hadoop-common:
org.apache.hadoop.crypto.random.TestOsSecureRandom
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4803//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4803//artifact/PreCommit-HADOOP-Build-patchprocess/newPatchFindbugsWarningshadoop-common.html
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4803//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch, HADOOP-11064.005.patch,
> HADOOP-11064.006.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146913#comment-14146913
]
Chris Nauroth commented on HADOOP-11064:
Thanks for the review, Colin. After I resolve this, I'll file a separate jira
for the follow-ups. We can resume discussion there.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch, HADOOP-11064.005.patch,
> HADOOP-11064.006.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146909#comment-14146909
]
Colin Patrick McCabe commented on HADOOP-11064:
---
Thank you for taking the lead on this, Chris. I still find this an unpleasant
solution, but it looks like what we're going to go with for 2.6. Sorry that I
have not had time to call a meeting due to schedule constraints.
+1 for the patch pending jenkins
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch, HADOOP-11064.005.patch,
> HADOOP-11064.006.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146841#comment-14146841
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12671029/HADOOP-11064.005.patch
against trunk revision 9fa5a89.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:red}-1 javac{color}. The applied patch generated 1265 javac
compiler warnings (more than the trunk's current 1263 warnings).
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4801//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4801//artifact/PreCommit-HADOOP-Build-patchprocess/newPatchFindbugsWarningshadoop-common.html
Javac warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4801//artifact/PreCommit-HADOOP-Build-patchprocess/diffJavacWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4801//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch, HADOOP-11064.005.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135696#comment-14135696
]
Chris Nauroth commented on HADOOP-11064:
[~cmccabe], my understanding is that we need to restore
{{nativeVerifyChunkedSums}}. (See method signature in Steve's comment from
05/Sep/14.)
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134803#comment-14134803
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12668920/HADOOP-11064.004.patch
against trunk revision 932ae03.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-common-project/hadoop-common:
org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4735//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4735//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch, HADOOP-11064.004.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130426#comment-14130426
]
Chris Nauroth commented on HADOOP-11064:
After further discussion, the following is a summary of potential solutions to
this problem:
1. Freeze the libhadoop.so API forever.
2. Library versioning plus maintaining a library on the servers for each
supported release.
3. Bundle the .dll or .so file inside a jar somehow so that YARN / Slider can
distribute it.
#1. Advantages:
* ???
#1. Disadvantages:
* We're unable to improve libhadoop.so in the future.
* There will be puzzling interactions when mixing and matching versions.
"New" bugs in libhadoop.so will show up with old hadoop releases, causing
confusion in bug trackers.
* We don't have any way of enforcing C API stability. Jenkins doesn't check
for it, most Java programmers don't know how to achieve it.
* There is still no ability for applications using new Hadoop versions to
make use of old libhadoop.so versions, unless we adopt an even worse
compatibility policy that nothing new can be added to libhadoop.so.
* Given all of the above, this option seems to be off the table.
#2. Advantages:
* Simple to implement.
* There's already a patch that implements it.
* We want libhadoop.so library versioning anyway, even if we later adopt
another solution in addition to this
#2. Disadvantages:
* Admins using Slider / YARN will need to ensure that the appropriate
versions of libhadoop are present on the server.
#3. Advantages:
* "Cleanest" solution, since it allows us to reuse YARN's existing
distribution mechanisms.
#3. Disadvantages:
* There are technical challenges to bundling a library in a jar that we
haven't yet tackled.
Short-term, there is now agreement that the scope of this jira is to restore
the 2 function signatures that were removed to unblock downstream projects.
Colin plans to arrange a conference call for further discussion next week. The
details will be posted here for anyone who wants to join, and we'll also call
wider attention to this issue on the mailing lists.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128212#comment-14128212
]
Steve Loughran commented on HADOOP-11064:
-
# I have nothing against versioning, but IMO that can be a different JIRA, "add
versioning to the libhadoop". This JIRA is covering linkage errors which we can
fix.
# w.r.t patch 3, the log of exceptions should include the stack trace, perhaps.
bq. There are a few months until 2.6 will be released-- do we really need to
hack this?
Yes. Because those of us who have switched our code to only work against
branch-2 are the one finding bugs sooner rather than later. If we weren't, this
issue wouldn't have surfaced until hadoop-2.6 shipped —at which point the fixes
become an even bigger piece of firefighting in a sprint to get 2.6.1 out the
door the following week.
If branch-2 isn't in a state usable by anyone downstream, it doesn't get used,
regressions don't get picked up.
Right now, for us, it isn't usable —because we're the only team that's tried to
deploy HBase 0.98 on a Hadoop 2.6 codebase cluster.
Furthermore, I don't think it is "a hack", it is "retain the entry points which
hadoop 2.4 code expect of the native library"
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128027#comment-14128027
]
Chris Nauroth commented on HADOOP-11064:
bq. I agree, it would be great to see the Windows build of hadoop.dll use CMake.
Earlier today, I filed HADOOP-11080 to track this.
bq. It would be better to solve it inside YARN, than to force a draconian
internal API compatibility policy on to libhadoop.
I can't think of a feature request that can be made of YARN for this.
hadoop-common.jar essentially does not publish a versioned release of its
corresponding native component. Asking YARN to figure out the right matching
native build at submission time would be brittle. Asking the applications to
bundle the matching native build version themselves pushes the build complexity
that we haven't solved down to our downstream consumers.
Hopefully I didn't imply that YARN could figure out how to distribute the
dependency. What I really wanted to convey is that hadoop-common-.jar
is tightly coupled to a specific version of libhadoop.so, and if libhadoop.so
was inside the jar, then it would solve the problem for all applications that
want to bundle a specific Hadoop jar version and submit that as a YARN
application.
bq. Also, what are the "old" function signatures? The ones for Hadoop 2.4? 2.5?
2.5.1?
That's a fair point. The specific bug report here involves a 2.4.0 YARN
application submitted to a 2.6.0 YARN cluster, but I don't know what other
incompatibilities we'd expose with other version combinations.
bq. I am + 1 for v3 of the patch... and based on previous conversations, I
think most people would be OK with adding versioning to libhadoop.
I heard a general desire for .so versioning. (The .so version has been at
1.0.0 forever as far as I can tell.) I could be wrong, but I don't think I
heard general consensus for the scheme implemented in the patch. This is not
standard .so versioning. Instead, it's a whole new library name with every
release, even minor releases. Just so everyone is on the same page, here is
what we get from a release with this patch:
{code}
> ll hadoop-3.0.0-SNAPSHOT/lib/native/libhadoop*.so*
lrwxrwxrwx 1 cnauroth 33 Sep 9 20:49
hadoop-3.0.0-SNAPSHOT/lib/native/libhadoop-3.0.0-SNAPSHOT.so ->
libhadoop-3.0.0-SNAPSHOT.so.1.0.0*
-rwxrwxr-x 1 cnauroth 763K Sep 9 20:49
hadoop-3.0.0-SNAPSHOT/lib/native/libhadoop-3.0.0-SNAPSHOT.so.1.0.0*
{code}
This means that during upgrades, the cluster administrator or the distro
packaging must maintain all prior versions. Otherwise, upgrading a cluster
from 2.4.0 to 2.4.1 risks link errors for applications that happen to bundle
the 2.4.0 jar. In this sense, I'm concerned that the patch actually makes the
situation worse. It certainly changes the maintenance and deployment model.
With consideration of that, are you still +1?
bq. I apologize again for being difficult here...
No apologies necessary. This is all healthy discussion. You've presented fair
counter-points and handled the discussion respectfully. I hope I've handled my
end of the discussion as well as you have. :-)
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128018#comment-14128018
]
Todd Lipcon commented on HADOOP-11064:
--
Colin -- are you aware of any other changes in the recent history of libhadoop
where we broke APIs rather than just augmenting them? I agree the versioning
thing is a good idea, but also seems reasonable enough to provide the "relay"
methods if it's trivial to do so here.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127882#comment-14127882
]
Colin Patrick McCabe commented on HADOOP-11064:
---
bq. I think that's a good sign that we could port hadoop.dll to use CMake and
eliminate these kinds of pitfalls. That's a topic for another time though.
I agree, it would be great to see the Windows build of {{hadoop.dll}} use CMake.
bq. FWIW, I'd prefer some kind of solution that bundles the native build into a
versioned jar. As far as I can tell, that provides the cleanest isolation for
this use case. Unfortunately, the build infrastructure requirements for this
look infeasible to me in the short-term.
It seems like this is a general issue with native dependencies of jars
submitted through YARN. It would be better to solve it inside YARN, than to
force a draconian internal API compatibility policy on to libhadoop.
bq. These issues make me think the versioning solution needs additional design
work and buy-in from a large portion of the community before we settle on it.
Restoring the old function signatures would be helpful to unblock downstream
projects that are trying to test against 2.6.0-SNAPSHOT clusters right now.
Granted, 2.6.0-SNAPSHOT isn't a real release, so we're technically under no
obligation, but I see it as a matter of good citizenship.
I think the versioning solution does show good citizenship. We are going out
of our way to work around this issue with YARN and native dependencies. It's
not a perfect workaround, but I don't see how it can be, unless YARN is changed
to somehow distribute these dependencies (as you hinted at?)
Also, what are the "old" function signatures? The ones for Hadoop 2.4? 2.5?
2.5.1? libhadoop changes all the time and its development isn't frozen.
I am + 1 for v3 of the patch... and based on previous conversations, I think
most people would be OK with adding versioning to libhadoop. Perhaps bring it
up on hadoop-dev if you think this needs more eyes?
I apologize again for being difficult here... you guys have done a lot of good
work on the native library and on Windows support. But I want to make sure
we're not constrained in the future. It may be a while before we can get a
perfect solution to this.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127711#comment-14127711
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12667506/HADOOP-11064.003.patch
against trunk revision 3e8f353.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4686//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4686//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch,
> HADOOP-11064.003.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127581#comment-14127581
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12667487/HADOOP-11064.002.patch
against trunk revision 3e8f353.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4684//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch, HADOOP-11064.002.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127468#comment-14127468
]
Colin Patrick McCabe commented on HADOOP-11064:
---
bq. BTW, I believe the patch you posted would break Windows. NativeCodeLoader
would attempt to load hadoop-.dll, but the Windows native build hasn't
been updated to produce a hadoop-.dll instead of a hadoop.dll.
Perhaps I'm missing something obvious here, but shouldn't the following code be
enough to produce {{hadoop-.dll}} under Windows?
{code}
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(HADOOP_LIB_NAME hadoop-${HADOOP_VERSION})
add_dual_library(${HADOOP_LIB_NAME}
main/native/src/exception.c
{code}
Would be nice if someone could give the patch a try on Windows and give me some
feedback.
bq. I'm +1 for short-term reinstatement of the old function signatures and
ongoing work on the long-term policy. Colin, I agree that it's not ideal to
lock ourselves into maintaining every function signature that ever existed over
time. At least speaking for myself, I have no intention of pointing at this as
a precedent to block implementation of a proper versioning scheme. Hopefully
that helps ease some of the very legitimate concerns that you raised.
There are a few months until 2.6 will be released-- do we really need to hack
this? I think the versioning solution is quite clean and easy to implement.
Trying to mix build products from different releases, even as a short-term
solution, just puts us down the wrong path, I think-- the same as people trying
to mix jars from different releases.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127277#comment-14127277
]
Chris Nauroth commented on HADOOP-11064:
I'm +1 for short-term reinstatement of the old function signatures and ongoing
work on the long-term policy. Colin, I agree that it's not ideal to lock
ourselves into maintaining every function signature that ever existed over
time. At least speaking for myself, I have no intention of pointing at this as
a precedent to block implementation of a proper versioning scheme. Hopefully
that helps ease some of the very legitimate concerns that you raised.
BTW, I believe the patch you posted would break Windows. {{NativeCodeLoader}}
would attempt to load hadoop-.dll, but the Windows native build hasn't
been updated to produce a hadoop-.dll instead of a hadoop.dll.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126835#comment-14126835
]
Steve Loughran commented on HADOOP-11064:
-
I'd like to see this patch not reverting any of the changes, but offering the
existing API calls. On windows machines, the native lib is near-essential for
functionality; on linux it is the only way to get performance on IO. With
things like unix-socket shortcuts and native encryption, this only gets worse.
It shows up on YARN apps more than anywhere else because these apps are not
things built by bigtop or anyone else and pre-installed on the cluster. They
are apps submitted remotely —and to avoid problems with transitive dependencies
&c, they are moving towards a "submit all the JARs" strategy. Twill does this,
Tez does this, SLIDER-330 shows where it is on my todo list. This stops my code
being brittle against versions, but it only works if the right JAR is on the CP
We can't (currently) mandate that YARN apps know which platform lib to use, to
include it in their binaries and upload to it, so we do need a good story here.
Long term, I think
# some versioning like the current patch can work
# I think for windows, we should at least have a winutils.jar JAR that includes
the windows one. As chris points out, packaging gets complex here. Unless,
perhaps, it gets teased out and made its own self-contained hadop-tools project
that gets pre-published, potentially on a different release schedule.
Anyway, right now I'd be happier with a recovery of the old methods, while we
think of a good policy and how to implement it.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126415#comment-14126415
]
Hadoop QA commented on HADOOP-11064:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12667284/HADOOP-11064.001.patch
against trunk revision 7498dd7.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4674//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4674//console
This message is automatically generated.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126408#comment-14126408
]
Colin Patrick McCabe commented on HADOOP-11064:
---
I'm concerned that this will set a bad precedent here that we are unable to
change libhadoop.so between versions. We certainly have done this a lot in the
past, and it's important that we keep this flexibility. Since we have some
time before 2.6, shouldn't we consider the library renaming solution?
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126345#comment-14126345
]
Chris Nauroth commented on HADOOP-11064:
[~ste...@apache.org], did you want the scope of this jira focused on
reinstating the old native function signatures in {{NativeCrc32}}? That's the
fastest path to resolving the blocker.
The longer-term policy discussion is great too, but perhaps that's better
handled separately.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Assignee: Colin Patrick McCabe
>Priority: Blocker
> Attachments: HADOOP-11064.001.patch
>
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126265#comment-14126265
]
Allen Wittenauer commented on HADOOP-11064:
---
bq. unfortunately afaik Java doesn't provide a way to specify a particular so
version dependency.
I keep thinking that System.load("/full/path/libname.so.1.2.3") worked. (We
should be able to figure out the full path by just processing java.library.path
manually or maybe reading hadoop.native.dir or whatever.)
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126239#comment-14126239
]
Chris Nauroth commented on HADOOP-11064:
bq. ...bundle everything, including the native code...
I think there is a reliance on the Maven jar file dependency as a reliable unit
of versioning. Applications expect that if they bundle their relevant Hadoop
jars all at the same version, then everything is going to work. Unfortunately,
it turns out that hadoop-common.jar is an "incomplete" artifact in terms of
Maven versioning because of the tight coupling between the jar and the native
code.
If we bundled the native libs inside hadoop-common.jar (or some new jar), and
extracted it automatically at runtime, then downstream projects could get a
completely versioned artifact through the Maven dependency. The snappy-java
project is an example of something that does this. It detects the OS and
extracts the corresponding native library at runtime. I believe hadoop-lzo has
just started doing something similar too.
Of course, this opens up a can of worms around release engineering. The
current Apache release process only builds the native components on a single
platform. I can't think of a way to make this work without a lot of
infrastructure work as a pre-requisite.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126207#comment-14126207
]
Todd Lipcon commented on HADOOP-11064:
--
bq. If nothing else, we should really properly version them instead of making
up wackadoodle numbers. (libhadoop.so has been 1.0.0 for how many releases now?
Probably since it was introduced!)
Agreed, but unfortunately afaik Java doesn't provide a way to specify a
particular so version dependency. I asked this on Quora a few years ago:
http://www.quora.com/Is-there-a-way-to-force-Java-to-load-a-particular-soversion-of-a-JNI-dependency
and unfortunately got no real answers.
So, does this mean we need to always keep binary compatibility of the
internal-facing libhadoop.so? Could we change hbase to pick up the Hadoop
libraries from HADOOP_HOME instead of bundling them? It seems like it should
either (a) bundle everything, including the native code, or (b) bundle nothing,
and load everything from HADOOP_HOME. What's causing a problem is that it's
using bundled jars with system-located native code.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125978#comment-14125978
]
Colin Patrick McCabe commented on HADOOP-11064:
---
bq. This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
rebuilt and repackaged with the hadoop- 2.6 JARs
I don't follow. What is to rebuild? If you put the Hadoop 2.6 jars on the
classpath and the hadoop 2.6 libhadoop.so on the classpath, your application
should work.
bq. Backward compatibility within a major version is usually expected from a
user perspective.
As Todd mentioned, we don't support mixing Hadoop 2.4 and Hadoop 2.6 jars on
the same CLASSPATH. Similarly, we don't support mixing a libhadoop.so from one
version with a libhadoop.so from another version. Backwards compatibility
refers to compatibility with the public APIs, not compatibility with internal,
non-public APIs.
There's been a few of these jiras recently where people seem to want to put
multiple versions of libhadoop.so on their classpath and expect it to work (I
guess it would be hadoop.dll on Windows). I don't understand the motivation
for doing this-- can't the launcher scripts for Windows simply set up the
CLASSPATH and LD_LIBRARY_PATH appropriately for the version being launched?
What am I missing?
If it's absolutely, positively necessary to support throwing multiple versions
of the libhadoop library on the classpath at once, we could inject the version
into the library name / version info.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125968#comment-14125968
]
Allen Wittenauer commented on HADOOP-11064:
---
If nothing else, we should really properly version them instead of making up
wackadoodle numbers. (libhadoop.so has been 1.0.0 for how many releases now?
Probably since it was introduced!)
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125965#comment-14125965
]
Steve Loughran commented on HADOOP-11064:
-
I'm saying "if someone untars the hbase binaries and tries to use them in a
hadoop 2.6 cluster, they get to see a stack trace". HBase includes all its
JARs, which are 100% in sync, it's just that nobody bundles the native libs too.
I dont care about cross-JAR compatibility, but the changes in the .lib/.so code
stop me running any hadoop 2.4 code if the 2.6 libs are on their LIBPATH. That
includes standalone applications which would otherwise run happily without any
native JARs.
IMO those native bits of code are something we need to keep stable, even though
they are never intended for direct public use. We should also have the java
clients pick up version problems (2.6 code loading 2.4 lib)
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125799#comment-14125799
]
Nick Dimiduk commented on HADOOP-11064:
---
Backward compatibility within a major version is usually expected from a user
perspective.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125742#comment-14125742
]
Todd Lipcon commented on HADOOP-11064:
--
sorry, hit send too early:
Doing a fix to maintain the old private API is certainly an easy option like
you suggested, but it would be nice to have this compatibility guarantee
written down somewhere if we feel it is something we want to maintain. I'm -0
on guaranteeing support for mixed version classpaths, since the testing matrix
becomes quite large, and it means that *internal* APIs (these methods are
marked InterfaceAudience.Private) now need attention with regard to
compatibility. What distinguishes the shared library case from the mixed
hdfs/common case mentioned above?
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125735#comment-14125735
]
Todd Lipcon commented on HADOOP-11064:
--
[~ste...@apache.org] -- hmm, I'm not 100% following here. Are you suggesting
that we are supposed to support mixed-version installations? I'd always assumed
that, if someone is running hadoop 2.4 client, then they would _only_ have
hadoop 2.4 artifacts on their path (classpath and java.library.path alike).
Here you're saying that the user has Hadoop 2.4 jars with Hadoop 2.6 SOs on the
same classpath.
In the same way that we don't expect HDFS 2.6 to work with a Common 2.4 JAR, I
don't think this is a supported scenario. Is this scenario listed in any of our
compatibility documentation?
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122731#comment-14122731
]
Steve Loughran commented on HADOOP-11064:
-
The culprit appears to be that the {{nativeVerify}} methods have been renamed
{{nativeCompute}} and their signature changed. If they were private and in the
same class this would not be an issue —but they are really in the external
{{hadoop.so}} lib, which is now out of sync with any hadoop applications using
hadoop.jar < 2.6
{code}
private static native void nativeVerifyChunkedSums(
int bytesPerSum, int checksumType,
ByteBuffer sums, int sumsOffset,
ByteBuffer data, int dataOffset, int dataLength,
String fileName, long basePos);
{code}
After
{code}
private static native void nativeComputeChunkedSums(
int bytesPerSum, int checksumType,
ByteBuffer sums, int sumsOffset,
ByteBuffer data, int dataOffset, int dataLength,
String fileName, long basePos, boolean verify);
{code}
The obvious fix would be to reinstate the existing methods/signatures and relay
internally to the new methods.
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HADOOP-11064) UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32 method changes
[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122721#comment-14122721
]
Steve Loughran commented on HADOOP-11064:
-
Stack trace from HBase
{code}
FATAL [master:c6401:45972] master.HMaster: Unhandled exception.
Startingshutdown.java.lang.UnsatisfiedLinkError:
org.apache.hadoop.util.NativeCrc32.nativeVerifyChunkedSums(IILjava/nio/ByteBuffer;ILjava/nio/ByteBuffer;IILjava/lang/String;J)V
at org.apache.hadoop.util.NativeCrc32.nativeVerifyChunkedSums(Native Method)
at org.apache.hadoop.util.NativeCrc32.verifyChunkedSums(NativeCrc32.java:57)
at org.apache.hadoop.util.DataChecksum.verifyChunkedSums(DataChecksum.java:291)
at
org.apache.hadoop.hdfs.BlockReaderLocal.doByteBufferRead(BlockReaderLocal.java:338)
at
org.apache.hadoop.hdfs.BlockReaderLocal.fillSlowReadBuffer(BlockReaderLocal.java:388)
at org.apache.hadoop.hdfs.BlockReaderLocal.read(BlockReaderLocal.java:408)
at
org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:642)
at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:698)
at
org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:752)
at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:793)
at java.io.DataInputStream.read(DataInputStream.java:149)
at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:192)
at org.apache.hadoop.hbase.util.FSUtils.getVersion(FSUtils.java:495)
at org.apache.hadoop.hbase.util.FSUtils.checkVersion(FSUtils.java:582)
at
org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:460)
at
org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:151)
at
org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:128)
at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:790)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:603)
at java.lang.Thread.run(Thread.java:744)
{code}
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
>Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
>Reporter: Steve Loughran
>Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
