See https://builds.apache.org/job/Hadoop-Common-trunk/1083/changes
Changes:
[wheat9] HDFS-6164. Remove lsr in OfflineImageViewer. Contributed by Haohui Mai.
[jeagles] HADOOP-10442. Group look-up can cause segmentation fault when certain
JNI-based mapping module is used. (Kihwal Lee via
Hi folks,
Even as 2.3 was released, several dependencies of hadoop are quite dated.
And more and more of them are causing friction for hadoop-related libraries
and hadoop users in general, as these dependency versions are often
incompatibly different than the versions most people use these days.
My understanding is that unfortunately we're stuck with these for the rest
of 2.x, because changing them could break jobs that rely on them. For jobs
that want to use newer versions, the recommendation is to use
mapreduce.user.classpath.first or turn on classpath isolation with
I don't disagree about version age -I've just been downgrading a project to
use some of the versions. The issue with YARN apps is that you get these on
your classpath.
1. There's a JIRA: https://issues.apache.org/jira/browse/HADOOP-9991
2. Nobody is working full time on these, I
Given the fact that Java 6 is EOL for a while, I wonder, when is a good
time to drop the support of java 6 in trunk?
New functionalities in JDK7 such as file system watcher can simplify the
implementation of the name node and the data node in HDFS.
On Fri, Mar 28, 2014 at 10:30 AM, Steve
On 28 March 2014 17:00, Sandy Ryza sandy.r...@cloudera.com wrote:
My understanding is that unfortunately we're stuck with these for the rest
of 2.x, because changing them could break jobs that rely on them. For jobs
that want to use newer versions, the recommendation is to use
Chris Nauroth created HADOOP-10450:
--
Summary: Build zlib native code bindings in hadoop.dll for Windows.
Key: HADOOP-10450
URL: https://issues.apache.org/jira/browse/HADOOP-10450
Project: Hadoop
Regarding JDK7, we have at least one jira I'm aware of proposing several
improvements that we can make in our code by using new JDK7 APIs.
https://issues.apache.org/jira/browse/HADOOP-9590
If anyone wants to repurpose this as a master JDK7 enhancement jira and
start cataloging additional
I think we need some way of isolating YARN, MR, and HDFS clients from
the Hadoop dependencies. Anything else just isn't sane... whatever we
may say, there will always be clients that rely on the dependencies
that we pull in, if we make those visible. I can't really blame
clients for this. It's
We've successfully supported CDH4.2+ on Java 7 as well as CDH5, so I think
that code wise we're ready to move to 7. However, we can't start using Java
7-only features in the 2.x line for compatibility reasons.
Also, even if the compatibility guidelines state that we can bump our
dependencies
10 matches
Mail list logo
